From: Paul L. <pa...@sq...> - 2005-11-23 23:42:46
|
All, Haven't gotten the time to review the templating stuff in detail, but I finally got to open a template file and see that there is a large amount of logic in there. I don't want to make rash accusations, since logic in template files is not bad in and of itself, and with the amount of things that we can do with SM, this will probably not ever change that much.... I guess I just wanted to voice a little concern that we make sure that all the logic is strictly to make interface decisions. The specific issue I ran across was that the subject_link hook has been removed entirely. I am about to add it back, and was a little surprised to see that the mailbox_form_before, mailbox_index_before, and mailbox_index_after hooks are left in the template. Off the top of my head, I am not sure what plugins use those hooks and what they do, but I am worried about two things here: - Non-PHP templates may or may not be able to run PHP hooks, or if they can, they may not provide all of the global (and even non-global) context and function call arguments that the hooks require. I do not really like the idea of just dumping hooks as-is into the templates without more thought about ways we can support hooks in templates no matter the implementation. This is what I had tried to voice in numerous emails previously, but I guess didn't really get through. Is there anything anyone can think of to perhaps provide a different hooking mechanism in the template class itself? At the very least, we need to make sure the hooks left in the templates are being used for plugins to spit out add-on HTML code, no more.... and that any context they need is provided perhaps explicitly via mechanisms that are extensible to other template paradigms. - In the case of subject_link hook, which does in fact just allow plugins to add stuff to the <a> tag that encases the subject (most commonly to add a target attribute). Even though it is a HTML add-on hook, my inclination is NOT to put it in the template; instead put it back in mailbox_display, where it can still enjoy the same access to SM/PHP context without the above concerns and can simply add extra information to whatever is put in the template (I think I will have to add some kind of "extra link attributes" entry for the subject of each message). It would be nice if we could pull all hooks back into the core in this manner and then talk later about adding a different hook mechanism (or even the same one, just with different, template-specific hook names) for templates so that plugins can interact the same as they always have with SM and differently with templates if they need to. |
From: Fredrik J. <sqm...@fi...> - 2005-11-24 08:47:27
|
> Haven't gotten the time to review the templating stuff in detail, but > I finally got to open a template file and see that there is a large > amount of logic in there. I don't want to make rash accusations, since > logic in template files is not bad in and of itself, and with the amount > of things that we can do with SM, this will probably not ever change that > much.... I guess I just wanted to voice a little concern that we make sure > that all the logic is strictly to make interface decisions. > > The specific issue I ran across was that the subject_link hook has > been removed entirely. I am about to add it back, and was a little > surprised to see that the mailbox_form_before, mailbox_index_before, and > mailbox_index_after hooks are left in the template. Off the top of my > head, I am not sure what plugins use those hooks and what they do, but I > am worried about two things here: > > - Non-PHP templates may or may not be able to run PHP hooks, or if they > can, they may not provide all of the global (and even non-global) context > and function call arguments that the hooks require. I do not really like > the idea of just dumping hooks as-is into the templates without more > thought about ways we can support hooks in templates no matter the > implementation. This is what I had tried to voice in numerous emails > previously, but I guess didn't really get through. Is there anything > anyone can think of to perhaps provide a different hooking mechanism in > the template class itself? At the very least, we need to make sure the > hooks left in the templates are being used for plugins to spit out add-on > HTML code, no more.... and that any context > they need is provided perhaps explicitly via mechanisms that are > extensible to other template paradigms. I'm not sure, because I'm writing this on an impulse, but wouldn't that mean that we need to (almost) double the amount of hooks? The ones we have today must be left for the logic of the plugins, and then some new ones to add HTML to the pages sent to the end user. The hooks we have today should not be allowed to print anything anyway, but return an array of strings (one string per plugin using that hook). Until templating is done, we could have a function that prints all posts in such an array, but it should really be handled by the templating when that's finished. > - In the case of subject_link hook, which does in fact just allow > plugins to add stuff to the <a> tag that encases the subject (most > commonly to add a target attribute). Even though it is a HTML add-on > hook, my inclination is NOT to put it in the template; instead put it > back in mailbox_display, where it can still enjoy the same access to > SM/PHP context without the above concerns and can simply add extra > information to whatever is put in the template (I think I will have to > add some kind of "extra link attributes" entry for the subject of each > message). It would be nice if we could pull all hooks back into the core > in this manner and then talk later about adding a different hook mechanism > (or even the same one, just with different, template-specific > hook names) for templates so that plugins can interact the same as they > always have with SM and differently with templates if they need to. Ah. (Close to) Double the amount of hooks. Sincerely, Fredrik. |
From: Paul L. <pa...@sq...> - 2005-11-24 09:12:57
|
>>Haven't gotten the time to review the templating stuff in detail, but >>I finally got to open a template file and see that there is a large >>amount of logic in there. I don't want to make rash accusations, since >>logic in template files is not bad in and of itself, and with the amount >>of things that we can do with SM, this will probably not ever change that >>much.... I guess I just wanted to voice a little concern that we make sure >>that all the logic is strictly to make interface decisions. >> >>The specific issue I ran across was that the subject_link hook has >>been removed entirely. I am about to add it back, and was a little >>surprised to see that the mailbox_form_before, mailbox_index_before, and >>mailbox_index_after hooks are left in the template. Off the top of my >>head, I am not sure what plugins use those hooks and what they do, but I >>am worried about two things here: >> >>- Non-PHP templates may or may not be able to run PHP hooks, or if they >>can, they may not provide all of the global (and even non-global) context >>and function call arguments that the hooks require. I do not really like >>the idea of just dumping hooks as-is into the templates without more >>thought about ways we can support hooks in templates no matter the >>implementation. This is what I had tried to voice in numerous emails >>previously, but I guess didn't really get through. Is there anything >>anyone can think of to perhaps provide a different hooking mechanism in >>the template class itself? At the very least, we need to make sure the >>hooks left in the templates are being used for plugins to spit out add-on >>HTML code, no more.... and that any context >>they need is provided perhaps explicitly via mechanisms that are >>extensible to other template paradigms. > > > I'm not sure, because I'm writing this on an impulse, but wouldn't that > mean that we need to (almost) double the amount of hooks? I don't think so. Duplication of hooks is actually probably a bad and confusing thing. > The ones we have > today must be left for the logic of the plugins, and then some new ones to > add HTML to the pages sent to the end user. I don't think it's always that simple to split one hook into its SM/PHP context to get the logic down and then a template/interface hook to output the needed HTML based on the earlier PHP hook logic. It's an idea, but a harder one to code and probably overkill(?). (and it's not what I was advocating for above) > The hooks we have today should > not be allowed to print anything anyway, but return an array of strings > (one string per plugin using that hook). I mostly agree, although there are some places where the code isn't structured for that. But I think I'd be willing to say that if we fix those places that your statement is probably what we want to aim for. > Until templating is done, we > could have a function that prints all posts in such an array, but it > should really be handled by the templating when that's finished. OK, I'll only add that sometimes it's going to be simpler than having an array, and sometimes it's going to be a lot more complex, especially if the output then needs to be funnelled by the core into a template. This is in fact what I did when I reimplemented the subject_link hook earlier today. But regardless of complexity I think I could live with this (however, I will still advocate for the possibility to have some pure-template hooks in order to inject one of SM's most powerful and popular technologies into the templates -- but I want to talk about possibly doing it in a way that is compatible with potentially non-PHP templating engines (in the real world, are there any?)). >>- In the case of subject_link hook, which does in fact just allow >>plugins to add stuff to the <a> tag that encases the subject (most >>commonly to add a target attribute). Even though it is a HTML add-on >>hook, my inclination is NOT to put it in the template; instead put it >>back in mailbox_display, where it can still enjoy the same access to >>SM/PHP context without the above concerns and can simply add extra >>information to whatever is put in the template (I think I will have to >>add some kind of "extra link attributes" entry for the subject of each >>message). It would be nice if we could pull all hooks back into the core >>in this manner and then talk later about adding a different hook mechanism >>(or even the same one, just with different, template-specific >>hook names) for templates so that plugins can interact the same as they >>always have with SM and differently with templates if they need to. > > > Ah. (Close to) Double the amount of hooks. No. I think you mis-read my point. I am saying we keep as many of our current hooks in the core (remove them from the templates where they exist now), yet allow a (possibly technically different) hook system to exist simultaneously in the templates because some hooks merely need to spit out some mindless HTML without the need to interact with any core variables or functionalities. Which hooks those are remains to be seen - some will be new hooks I think. I don't think there is any reason why we'd need a 2nd hook for each one we have now. |
From: Paul L. <pa...@sq...> - 2005-11-25 21:03:04
|
> I finally got to open a template file and see that there is a large > amount of logic in there. I don't want to make rash accusations, since > logic in template files is not bad in and of itself, and with the amount > of things that we can do with SM, this will probably not ever change > that much.... I guess I just wanted to voice a little concern that we > make sure that all the logic is strictly to make interface decisions. I looked a little closer at message_list.tpl today. I think that there is way too much logic in the "template": - I don't see any reason why the section called 'Calculate string "Viewing message x to y (z total)"' can't be done in the core, where the x y and z variables are calculated and handed to the template to be used as needed - I am not yet sure exactly why $aSortSupported is built in the template - Many constants such as all the column constants and SM_PATH seem to be being accessed not via the template, which I think violates the template model - There should be a form_action instead of assuming php_self - I think variable names should be more verbose than $t - OMG, the logic in util_paginator.php is insane. Why is it that we cannot construct a set of values with associated link values in the core and remove all of that? - Yeesh, util_message_list.php is just a little better, but why does any of this have to be done in the template? - In some place, regular gettext _("...") syntax is used, in others, things like button text seem to be pre-translated and handed to the template. I like the idea that all text is pre-translated because not some templating engines may not have access to the same (or any) translation engine. - We probably need to figure out a place to have some centralized documentation of all the variables handed to the template; some of them are obvious, but some are a bit obscure (especially arrays/nested arrays) In general, I think one of the main goals in how we design the templates is to make them as accessible as possible to designers and other people who may be less skilled at any kind of programming. Another obvious goal is to keep the HTML code in one place, as sequential as possible, not interspersed in logic and abstracted into other functions. I do not think we have succeeded so far. Weeding out the HTML from the logic in some of these places such as util_paginator.php is over the top and will not encourage wide-spread "templatization", since only people who are willing to dive in deep to that code will build templates. Also, having to duplicate that logic for people building their own templates from the ground up or in another template engine is too much to expect I think, especially if we can do a lot of that logic for them. Marc, please don't take offence. ;) -paul |
From: Marc G. K. <ma...@sq...> - 2005-11-26 08:56:48
|
On Fri, November 25, 2005 22:00, Paul Lesneiwski wrote: >> I finally got to open a template file and see that there is a large >> amount of logic in there. I don't want to make rash accusations, since >> logic in template files is not bad in and of itself, and with the >> amount of things that we can do with SM, this will probably not ever >> change that much.... I guess I just wanted to voice a little concern >> that we make sure that all the logic is strictly to make interface >> decisions. > > I looked a little closer at message_list.tpl today. I think that there > is way too much logic in the "template": Yes there is because it is NOT the final template. I.e., normally you use different templatete sets for js or non js templates which reduces the logic a bit. The only goal of the "template" you were looking at it seperating UI related logic from the rest. As you know i'm much more interested in core logic then templates stuff so I separated the stuff, asks multiple time for constructive feedback and 8 months later nobody touched the template thouroughly. > > - I don't see any reason why the section called 'Calculate string > "Viewing message x to y (z total)"' can't be done in the core, where the > x y and z variables are calculated and handed to the template to be used as > needed It's UI related logic and it shouldn't be part of core. It's okay that this kind of logic takes place in a file in the template dorectory, see also how the paginator logic is separated . > > - I am not yet sure exactly why $aSortSupported is built in the template > Should be moved to the UI related logic section (util_*.php). > > - Many constants such as all the column constants and SM_PATH seem to > be being accessed not via the template, which I think violates the template > model > > - There should be a form_action instead of assuming php_self > > > - I think variable names should be more verbose than $t > > > - OMG, the logic in util_paginator.php is insane. Why is it that we > cannot construct a set of values with associated link values in the core > and remove all of that? Hey, i just ported the stuff, it was always there with one difference, i moved it in the UI logic related section. > > - Yeesh, util_message_list.php is just a little better, but why does > any of this have to be done in the template? > util_messages suppose to contain UI related logic that can be reused by other templates designers. Much of the UI related logic still in the .tpl files can be moved to the util_* files. > - In some place, regular gettext _("...") syntax is used, in others, > things like button text seem to be pre-translated and handed to the > template. I like the idea that all text is pre-translated because not > some templating engines may not have access to the same (or any) > translation engine. Good point. If you want to fix it ..., be my guest. > > - We probably need to figure out a place to have some centralized > documentation of all the variables handed to the template; some of them are > obvious, but some are a bit obscure (especially arrays/nested arrays) > > > In general, I think one of the main goals in how we design the templates > is to make them as accessible as possible to designers and other people who > may be less skilled at any kind of programming. Another obvious goal is > to keep the HTML code in one place, as sequential as possible, not > interspersed in logic and abstracted into other functions. I do not think > we have succeeded so far. Weeding out the HTML from the logic in some of > these places such as util_paginator.php is over the top and will not > encourage wide-spread "templatization", since only people who are willing > to dive in deep to that code will build templates. Also, having to > duplicate that logic for people building their own templates from the > ground up or in another template engine is too much to expect I think, > especially if we can do a lot of that logic for them. I disagree a bit. SquirrelMail is complex with all the user options and the message list is probably the most complex part for templates. I think a template designer must have more skills then only html skills otherwise they are not capable for designing squirrelmail templates. I agree we must move some of the logic to the util files to make the current template less complex. And once again, the util_* files are not templates but UI related logic files that shouldn't be touches by template designers so complexity in those files isn't a problem at all. > > Marc, please don't take offence. ;) I don't, i asked feedback and finally got it ;) I always said, first think thorougly about current approach before we continue with adapting the rest for templates. Marc. |
From: Paul L. <pa...@sq...> - 2005-11-28 07:41:51
|
>>>I finally got to open a template file and see that there is a large >>>amount of logic in there. I don't want to make rash accusations, since >>>logic in template files is not bad in and of itself, and with the >>>amount of things that we can do with SM, this will probably not ever >>>change that much.... I guess I just wanted to voice a little concern >>>that we make sure that all the logic is strictly to make interface >>>decisions. >> >>I looked a little closer at message_list.tpl today. I think that there >>is way too much logic in the "template": > > > Yes there is because it is NOT the final template. I.e., normally you use > different templatete sets for js or non js templates which reduces the > logic a bit. > The only goal of the "template" you were looking at it seperating UI > related logic from the rest. Are you suggesting that we should have a default template when js is detected/on and a different one for when it is unavailable/off? I'm not sure we need to go that far. I'm also not sure that's the most important logic in question here. >>- I don't see any reason why the section called 'Calculate string >>"Viewing message x to y (z total)"' can't be done in the core, where the >>x y and z variables are calculated and handed to the template to be used as >>needed > > > It's UI related logic and it shouldn't be part of core. It's okay that > this kind of logic takes place in a file in the template dorectory, see > also how the paginator logic is separated . I disagree. I think that it is a fuzzy line between the two, and when it comes to stuff like this -- logic that makes a template unecessarily complex -- I always do the math and logic in the core. In this case, if the core was given a starting message # and it has a size per page, then it is not unreasonable to expect that it can calculate the other page and paginator details, such as what page we are on, the total number of pages, and the paginator numbers and associated links. None of those things has any interface implication that I can see. Calculating them in core only makes the template job easier and much more straight-forward. The template takes those numbers and links and puts them into whatever format it needs. Template engines that are more simplistic then won't have to stretch to implement things like this, and even designers using powerful template engines don't necessarily care about constructing page numbers and pagination information when all they are doing is rearranging how those elements are shown. >>- I am not yet sure exactly why $aSortSupported is built in the template >> > > > Should be moved to the UI related logic section (util_*.php). > > >>- Many constants such as all the column constants and SM_PATH seem to >>be being accessed not via the template, which I think violates the template >>model >> >>- There should be a form_action instead of assuming php_self >> >> >>- I think variable names should be more verbose than $t >> >> >>- OMG, the logic in util_paginator.php is insane. Why is it that we >>cannot construct a set of values with associated link values in the core >>and remove all of that? > > > Hey, i just ported the stuff, it was always there with one difference, i > moved it in the UI logic related section. No argument about messy code; there is some messy code here and there, and we can clean it up as we go, but I *do* have issue with putting this in the realm of the templates - see below. >>- Yeesh, util_message_list.php is just a little better, but why does >>any of this have to be done in the template? >> > > > util_messages suppose to contain UI related logic that can be reused by > other templates designers. > Much of the UI related logic still in the .tpl files can be moved to the > util_* files. I think it is a mistake to put at least half of those functions in the template scope. If the goal is to be flexible for any template engine, then we can't expect that all implementations will be able to use the functions in those files so easily, if at all. Per my argument above, anything that is merely calculating a number or other element that is generic and is common to all templates should be simply done in core and handed to the template class to greatly simplify the template's job. >>- In some place, regular gettext _("...") syntax is used, in others, >>things like button text seem to be pre-translated and handed to the >>template. I like the idea that all text is pre-translated because not >>some templating engines may not have access to the same (or any) >>translation engine. > > Good point. If you want to fix it ..., be my guest. Heh. :) Well, it seems like it will have to be a gradual process, since I think there are a lot of those. :) >>- We probably need to figure out a place to have some centralized >>documentation of all the variables handed to the template; some of them are >>obvious, but some are a bit obscure (especially arrays/nested arrays) > > >> >>In general, I think one of the main goals in how we design the templates >>is to make them as accessible as possible to designers and other people who >>may be less skilled at any kind of programming. Another obvious goal is >>to keep the HTML code in one place, as sequential as possible, not >>interspersed in logic and abstracted into other functions. I do not think >>we have succeeded so far. Weeding out the HTML from the logic in some of >>these places such as util_paginator.php is over the top and will not >>encourage wide-spread "templatization", since only people who are willing >>to dive in deep to that code will build templates. Also, having to >>duplicate that logic for people building their own templates from the >>ground up or in another template engine is too much to expect I think, >>especially if we can do a lot of that logic for them. > > > I disagree a bit. SquirrelMail is complex with all the user options and > the message list is probably the most complex part for templates. I think > a template designer must have more skills then only html skills otherwise > they are not capable for designing squirrelmail templates. Sure, but I think that's a little bit of a cop-out, when I think there is more we can arguably do to simplify the templates. Calculating things that have no direct interface implications should be done in core, even if it is something like a list of page numbers and the pre-built links for each page. The more easy to understand, the more popular and powerful SM will become. > I agree we must move some of the logic to the util files to make the > current template less complex. I think we need to remove some more of the HTML that is buried in the util files, and I think we need to push many of those util functions into the core. > And once again, the util_* files are not templates but UI related logic > files that shouldn't be touches by template designers so complexity in > those files isn't a problem at all. So then they should be in the core. Cheers, Paul >>Marc, please don't take offence. ;) > > > I don't, i asked feedback and finally got it ;) I always said, first think > thorougly about current approach before we continue with adapting the rest > for templates. > > Marc. |
From: Marc G. K. <ma...@sq...> - 2006-01-30 08:05:29
|
Hello Paul, Thnx for the hint about the template discussion so let's continue. On Mon, November 28, 2005 8:39 am, Paul Lesneiwski wrote: > >>>> I finally got to open a template file and see that there is a large >>>> amount of logic in there. I don't want to make rash accusations, >>>> since logic in template files is not bad in and of itself, and with >>>> the amount of things that we can do with SM, this will probably not >>>> ever change that much.... I guess I just wanted to voice a little >>>> concern that we make sure that all the logic is strictly to make >>>> interface decisions. >>> >>> I looked a little closer at message_list.tpl today. I think that >>> there is way too much logic in the "template": >> >> >> Yes there is because it is NOT the final template. I.e., normally you >> use different templatete sets for js or non js templates which reduces >> the logic a bit. The only goal of the "template" you were looking at it >> seperating UI related logic from the rest. > > Are you suggesting that we should have a default template when js is > detected/on and a different one for when it is unavailable/off? I'm not > sure we need to go that far. I'm also not sure that's the most important > logic in question here. Yes I was suggesting that. > >>> - I don't see any reason why the section called 'Calculate string >>> "Viewing message x to y (z total)"' can't be done in the core, where >>> the x y and z variables are calculated and handed to the template to >>> be used as needed >> >> >> It's UI related logic and it shouldn't be part of core. It's okay that >> this kind of logic takes place in a file in the template dorectory, see >> also how the paginator logic is separated . > > I disagree. I think that it is a fuzzy line between the two, and when > it comes to stuff like this -- logic that makes a template unecessarily > complex -- I always do the math and logic in the core. In this case, if > the core was given a starting message # and it has a size per page, then > it is not unreasonable to expect that it can calculate the other page and > paginator details, such as what page we are on, the total number of pages, > and the paginator numbers and associated links. > > None of those things has any interface implication that I can see. > Calculating them in core only makes the template job easier and much > more straight-forward. The template takes those numbers and links and puts > them into whatever format it needs. Template engines that are more > simplistic then won't have to stretch to implement things like this, and > even designers using powerful template engines don't necessarily care > about constructing page numbers and pagination information when all they > are doing is rearranging how those elements are shown. > Okey, I agree that it probably makes more sense to calculate links outside the template. >>> - I am not yet sure exactly why $aSortSupported is built in the >>> template >>> >> >> >> Should be moved to the UI related logic section (util_*.php). >> >> >> >>> - Many constants such as all the column constants and SM_PATH seem to >>> be being accessed not via the template, which I think violates the >>> template model >>> >>> - There should be a form_action instead of assuming php_self >>> >>> >>> >>> - I think variable names should be more verbose than $t >>> >>> >>> >>> - OMG, the logic in util_paginator.php is insane. Why is it that we >>> cannot construct a set of values with associated link values in the >>> core and remove all of that? >> >> >> Hey, i just ported the stuff, it was always there with one difference, >> i moved it in the UI logic related section. > > No argument about messy code; there is some messy code here and there, > and we can clean it up as we go, but I *do* have issue with putting this in > the realm of the templates - see below. > >>> - Yeesh, util_message_list.php is just a little better, but why does >>> any of this have to be done in the template? >>> >> >> >> util_messages suppose to contain UI related logic that can be reused by >> other templates designers. Much of the UI related logic still in the >> .tpl files can be moved to the >> util_* files. > > I think it is a mistake to put at least half of those functions in the > template scope. If the goal is to be flexible for any template engine, > then we can't expect that all implementations will be able to use the > functions in those files so easily, if at all. Per my argument above, > anything that is merely calculating a number or other element that is > generic and is common to all templates should be simply done in core and > handed to the template class to greatly simplify the template's job. > I don't care where those UI related function are located. At this moment they are in the templates dir. The only thing I want to achieve is a strickt separation between SM core and SM UI. That means I DO NOT want function files in between the normal sm core function files that do UI related stuff like creating a paginator, calculating column width etc etc. Find a better place where we can stuff those functions. The only condition is that the UI related functions files are kept together in a single directory, separated from the rest. <snip> >>> - We probably need to figure out a place to have some centralized >>> documentation of all the variables handed to the template; some of >>> them are obvious, but some are a bit obscure (especially arrays/nested >>> arrays) >> >> >>> >>> In general, I think one of the main goals in how we design the >>> templates is to make them as accessible as possible to designers and >>> other people who may be less skilled at any kind of programming. >>> Another obvious goal is >>> to keep the HTML code in one place, as sequential as possible, not >>> interspersed in logic and abstracted into other functions. I do not >>> think we have succeeded so far. Weeding out the HTML from the logic >>> in some of these places such as util_paginator.php is over the top and >>> will not encourage wide-spread "templatization", since only people who >>> are willing to dive in deep to that code will build templates. Also, >>> having to duplicate that logic for people building their own templates >>> from the ground up or in another template engine is too much to expect >>> I think, >>> especially if we can do a lot of that logic for them. >> >> >> I disagree a bit. SquirrelMail is complex with all the user options and >> the message list is probably the most complex part for templates. I >> think a template designer must have more skills then only html skills >> otherwise they are not capable for designing squirrelmail templates. > > Sure, but I think that's a little bit of a cop-out, when I think there > is more we can arguably do to simplify the templates. Calculating things > that have no direct interface implications should be done in core, even if > it is something like a list of page numbers and the pre-built links for > each page. The more easy to understand, the more popular and powerful SM > will become. > >> I agree we must move some of the logic to the util files to make the >> current template less complex. > > I think we need to remove some more of the HTML that is buried in the > util files, and I think we need to push many of those util functions into > the core. > Make that the UI core, see my comments about separation above, >> And once again, the util_* files are not templates but UI related logic >> files that shouldn't be touches by template designers so complexity in >> those files isn't a problem at all. > > So then they should be in the core. .... ------------ To summarize, the discussion is about the amount of logic inside and outside the template and where that logic should be located. I think it should be easy to reduce complexity of current templates and probably it doesn't cost much time to simplify current templates. The biggest task when moving to templates is NOT the template it self but adapting de underlying SM core and rip out all html and the removal of html generating functions. That's why I think we can proceed with adapting the rest of SquirrelMail and create templates in whatever form we want. I do not think we are finished when we have our first rough templates. When the first rough templates are ready, people should stand up and decide where to draw the line regarding the complexity of the template and create utility functions to simplify that logic. Personally i'm interested in the first step till the rough templates are done. I'm not interested in the next step, creating the final templates. I think other people have more knowledge in that area. When we are done with cleaning up squirrelmail and work with templates the next step should take place. Move to a single entry page and get rid of frames. Regards, Marc. |
From: Paul L. <pa...@sq...> - 2006-01-31 05:35:19
|
> >>>> I finally got to open a template file and see that there is a large > >>>> amount of logic in there. I don't want to make rash accusations, > >>>> since logic in template files is not bad in and of itself, and with > >>>> the amount of things that we can do with SM, this will probably not > >>>> ever change that much.... I guess I just wanted to voice a little > >>>> concern that we make sure that all the logic is strictly to make > >>>> interface decisions. > >>> > >>> I looked a little closer at message_list.tpl today. I think that > >>> there is way too much logic in the "template": > >> > >> > >> Yes there is because it is NOT the final template. I.e., normally you > >> use different templatete sets for js or non js templates which reduces > >> the logic a bit. The only goal of the "template" you were looking at i= t > >> seperating UI related logic from the rest. > > > > Are you suggesting that we should have a default template when js is > > detected/on and a different one for when it is unavailable/off? I'm no= t > > sure we need to go that far. I'm also not sure that's the most importa= nt > > logic in question here. > > Yes I was suggesting that. Shouldn't the administrator (or maybe the user if the admin is nice enough) determine what the look and feel of the application should be? Unless we plan to duplicate each template page with a non-JavaScript-enabled copy, which seems like a lot of overkill, I think JavaScript support should not be a determining factor for which template is used. Seems better to continue doing JavaScript support as we already have been. "Correctly" coded templates would make use of the $javascript_on variable and act accordingly. But in the end, I don't think we need to waste our time on this fine of a point, since I would be very surprised to see duplicated sets of JavaScript and non-JavaScript templates evolve. > >>> - I don't see any reason why the section called 'Calculate string > >>> "Viewing message x to y (z total)"' can't be done in the core, where > >>> the x y and z variables are calculated and handed to the template to > >>> be used as needed > >> > >> > >> It's UI related logic and it shouldn't be part of core. It's okay that > >> this kind of logic takes place in a file in the template dorectory, se= e > >> also how the paginator logic is separated . > > > > I disagree. I think that it is a fuzzy line between the two, and when > > it comes to stuff like this -- logic that makes a template unecessarily > > complex -- I always do the math and logic in the core. In this case, i= f > > the core was given a starting message # and it has a size per page, the= n > > it is not unreasonable to expect that it can calculate the other page a= nd > > paginator details, such as what page we are on, the total number of pag= es, > > and the paginator numbers and associated links. > > > > None of those things has any interface implication that I can see. > > Calculating them in core only makes the template job easier and much > > more straight-forward. The template takes those numbers and links and = puts > > them into whatever format it needs. Template engines that are more > > simplistic then won't have to stretch to implement things like this, an= d > > even designers using powerful template engines don't necessarily care > > about constructing page numbers and pagination information when all the= y > > are doing is rearranging how those elements are shown. > > > > Okey, I agree that it probably makes more sense to calculate links outsid= e > the template. OK, someone can move it. I suppose that should be me since I brought it up= . :) > >>> - I am not yet sure exactly why $aSortSupported is built in the > >>> template > >>> > >> > >> > >> Should be moved to the UI related logic section (util_*.php). > >> > >> > >> > >>> - Many constants such as all the column constants and SM_PATH seem to > >>> be being accessed not via the template, which I think violates the > >>> template model This should definitely be fixed IMO. > >>> - There should be a form_action instead of assuming php_self This too, but it's a small thing. > >>> - I think variable names should be more verbose than $t This is just cleanup. > >>> - OMG, the logic in util_paginator.php is insane. Why is it that we > >>> cannot construct a set of values with associated link values in the > >>> core and remove all of that? > >> > >> > >> Hey, i just ported the stuff, it was always there with one difference, > >> i moved it in the UI logic related section. > > > > No argument about messy code; there is some messy code here and there, > > and we can clean it up as we go, but I *do* have issue with putting thi= s in > > the realm of the templates - see below. > > > >>> - Yeesh, util_message_list.php is just a little better, but why does > >>> any of this have to be done in the template? > >>> > >> > >> > >> util_messages suppose to contain UI related logic that can be reused b= y > >> other templates designers. Much of the UI related logic still in the > >> .tpl files can be moved to the > >> util_* files. > > > > I think it is a mistake to put at least half of those functions in the > > template scope. If the goal is to be flexible for any template engine, > > then we can't expect that all implementations will be able to use the > > functions in those files so easily, if at all. Per my argument above, > > anything that is merely calculating a number or other element that is > > generic and is common to all templates should be simply done in core an= d > > handed to the template class to greatly simplify the template's job. > > > > I don't care where those UI related function are located. At this moment > they are in the templates dir. The only thing I want to achieve is a > strickt separation between SM core and SM UI. That means I DO NOT want > function files in between the normal sm core function files that do UI > related stuff like creating a paginator, calculating column width etc etc= . Absolutely. No argument here. This is where Fredrik's thoughts seem applicable. I have long dreampt of a much more modular SM -- mostly meaning that I'd really like to see the OO design and coding of the delivery mechanisms completed and then do the same thing to all the other applicable components. Right now, the API is a little hard to grasp (although it is powerful and we shouldn't remove it all, just make the more common actions easier to accomplish for anyone who wants to use them -- plugins, core, or possibly an authorized 3rd party).=20 Um, where I am going with this is that I think the way page requests are handled today, we are still really limited in our API - core calls are litered all over the place - it's pretty ugly in some places.=20 It'd be really great if we could tell template developers that all they have to do to get a concisely packaged list of X number of messages for a message list is to merely call one function. Actually, that call would be above the level of the template (in the middle layer that Fredrik refers to), but I hope you can see what I am getting at. Stuff like that might also help make SM WAP-able and things like that too. So when I say I think all that logic is misplaced in the template directory, I am NOT implying that we should litter the "core" with those kinds of things. We agree that the two do not belong in the same place. What I was implying is what Fredrik explicitly stated.=20 When I develop templated sites, my usual methodology is to create a set of library files that offer an API. These files are in a separate directory and define a core functionality that knows nothing about how the data will be used. They just take requests and give some data back. Then I have a set of front-line files that receive the page requests, get the right data from the application library/API, and put it together and make any lightweight changes dictated by the user request. The templates aren't any part of this.... the templates then merely take all the preprocessed data and SHOW it. They don't FIGURE OUT anything. Really long answer, sorry for being so verbose. > Find a better place where we can stuff those functions. The only conditio= n > is that the UI related functions files are kept together in a single > directory, separated from the rest. So I think we might all agree that we can create a "middle" layer between core and template. The problem here is that I would suggest that that layer should be the recipient of the page requests. I think our code might not be ready for that yet. I'll have to look to see if there is a good place to try it out. Actually, though, the separation between the src/ directory and the functions/ and classes/ directories isn't so far off. The src/ files just need a lot of work. :) And maybe a new directory name that is more indicative of their purpose. To bring this back down to earth, I think the functions that I originally asked about should be contained either in the src/ directory or another directory intended to hold files with functions that generate generic, non-template-specific display data. And following up on the discussion on the CVS list, I think the src/ files should construct all translated strings and assign them to the templates already translated. > >>> - We probably need to figure out a place to have some centralized > >>> documentation of all the variables handed to the template; some of > >>> them are obvious, but some are a bit obscure (especially arrays/neste= d > >>> arrays) > >> > >> > >>> > >>> In general, I think one of the main goals in how we design the > >>> templates is to make them as accessible as possible to designers and > >>> other people who may be less skilled at any kind of programming. > >>> Another obvious goal is > >>> to keep the HTML code in one place, as sequential as possible, not > >>> interspersed in logic and abstracted into other functions. I do not > >>> think we have succeeded so far. Weeding out the HTML from the logic > >>> in some of these places such as util_paginator.php is over the top an= d > >>> will not encourage wide-spread "templatization", since only people wh= o > >>> are willing to dive in deep to that code will build templates. Also, > >>> having to duplicate that logic for people building their own template= s > >>> from the ground up or in another template engine is too much to expec= t > >>> I think, > >>> especially if we can do a lot of that logic for them. > >> > >> > >> I disagree a bit. SquirrelMail is complex with all the user options an= d > >> the message list is probably the most complex part for templates. I > >> think a template designer must have more skills then only html skills > >> otherwise they are not capable for designing squirrelmail templates. > > > > Sure, but I think that's a little bit of a cop-out, when I think there > > is more we can arguably do to simplify the templates. Calculating thin= gs > > that have no direct interface implications should be done in core, even= if > > it is something like a list of page numbers and the pre-built links for > > each page. The more easy to understand, the more popular and powerful = SM > > will become. > > > >> I agree we must move some of the logic to the util files to make the > >> current template less complex. > > > > I think we need to remove some more of the HTML that is buried in the > > util files, and I think we need to push many of those util functions in= to > > the core. > > > > Make that the UI core, see my comments about separation above, OK, I think we probably agree, so I didn't need to be so damn verbose above. :-\ > >> And once again, the util_* files are not templates but UI related logi= c > >> files that shouldn't be touches by template designers so complexity i= n > >> those files isn't a problem at all. > > > > So then they should be in the core. > > .... > ------------ > > To summarize, the discussion is about the amount of logic inside and > outside the template and where that logic should be located. > > I think it should be easy to reduce complexity of current templates and > probably it doesn't cost much time to simplify current templates. Mmm, there is some heavy-duty weeding of HTML from PHP still in many of the files, so I think it's a bigger job than that. But that does not affect this discussion. > The biggest task when moving to templates is NOT the template it self but > adapting de underlying SM core and rip out all html and the removal of > html generating functions. I think BOTH are a big job and require a good amount of forethought.=20 Don't short-sell the presentation layer. That "middle" layer needs to be well organized... and the more modular we can make it and the core that it uses, the more powerful we will make SM! Yay! > That's why I think we can proceed with adapting the rest of SquirrelMail > and create templates in whatever form we want. I do not think we are > finished when we have our first rough templates. When the first rough > templates are ready, people should stand up and decide where to draw the > line regarding the complexity of the template and create utility function= s > to simplify that logic. I think I disagree. The organization of the "middle" or "presentation" layer should be thought out, not thrown together hodge-podge. That code is just as important as any other piece and should not be treated like a second-class afterthought. That is what creates the spaghetti that we currently suffer from in several places. I don't think we are very far away from agreeing on something, so I don't think it's a lot to ask for us to nail down some basic architecture decisions before we get too far with the rest. > Personally i'm interested in the first step till the rough templates are > done. I'm not interested in the next step, creating the final templates. = I > think other people have more knowledge in that area. I feel the same. I am not a designer. However, templating system architecture IS something that WE have to get straight, and it is a SEPARATE (and important) discussion from UI design. > When we are done with cleaning up squirrelmail and work with templates th= e > next step should take place. Move to a single entry page and get rid of > frames. Awww, I like frames. :-p Cheers, Paul |
From: Daniel W. <d...@ni...> - 2006-02-19 00:44:52
|
[nothing inline - scroll to bottom] >>>>>>I finally got to open a template file and see that there is a large >>>>>> amount of logic in there. I don't want to make rash accusations, >>>>>>since logic in template files is not bad in and of itself, and with >>>>>>the amount of things that we can do with SM, this will probably not >>>>>>ever change that much.... I guess I just wanted to voice a little >>>>>>concern that we make sure that all the logic is strictly to make >>>>>>interface decisions. >>>>> >>>>>I looked a little closer at message_list.tpl today. I think that >>>>>there is way too much logic in the "template": >>>> >>>> >>>>Yes there is because it is NOT the final template. I.e., normally you >>>>use different templatete sets for js or non js templates which reduces >>>>the logic a bit. The only goal of the "template" you were looking at it >>>>seperating UI related logic from the rest. >>> >>>Are you suggesting that we should have a default template when js is >>>detected/on and a different one for when it is unavailable/off? I'm not >>>sure we need to go that far. I'm also not sure that's the most important >>>logic in question here. >> >>Yes I was suggesting that. > > > Shouldn't the administrator (or maybe the user if the admin is nice > enough) determine what the look and feel of the application should be? > Unless we plan to duplicate each template page with a > non-JavaScript-enabled copy, which seems like a lot of overkill, I > think JavaScript support should not be a determining factor for which > template is used. Seems better to continue doing JavaScript support > as we already have been. "Correctly" coded templates would make use > of the $javascript_on variable and act accordingly. > > But in the end, I don't think we need to waste our time on this fine > of a point, since I would be very surprised to see duplicated sets of > JavaScript and non-JavaScript templates evolve. > > >>>>>- I don't see any reason why the section called 'Calculate string >>>>>"Viewing message x to y (z total)"' can't be done in the core, where >>>>>the x y and z variables are calculated and handed to the template to >>>>>be used as needed >>>> >>>> >>>>It's UI related logic and it shouldn't be part of core. It's okay that >>>>this kind of logic takes place in a file in the template dorectory, see >>>>also how the paginator logic is separated . >>> >>>I disagree. I think that it is a fuzzy line between the two, and when >>>it comes to stuff like this -- logic that makes a template unecessarily >>>complex -- I always do the math and logic in the core. In this case, if >>>the core was given a starting message # and it has a size per page, then >>>it is not unreasonable to expect that it can calculate the other page and >>>paginator details, such as what page we are on, the total number of pages, >>>and the paginator numbers and associated links. >>> >>>None of those things has any interface implication that I can see. >>>Calculating them in core only makes the template job easier and much >>>more straight-forward. The template takes those numbers and links and puts >>>them into whatever format it needs. Template engines that are more >>>simplistic then won't have to stretch to implement things like this, and >>>even designers using powerful template engines don't necessarily care >>>about constructing page numbers and pagination information when all they >>>are doing is rearranging how those elements are shown. >>> >> >>Okey, I agree that it probably makes more sense to calculate links outside >>the template. > > > OK, someone can move it. I suppose that should be me since I brought it up. :) > > >>>>>- I am not yet sure exactly why $aSortSupported is built in the >>>>>template >>>>> >>>> >>>> >>>>Should be moved to the UI related logic section (util_*.php). >>>> >>>> >>>> >>>> >>>>>- Many constants such as all the column constants and SM_PATH seem to >>>>> be being accessed not via the template, which I think violates the >>>>>template model > > > This should definitely be fixed IMO. > > >>>>>- There should be a form_action instead of assuming php_self > > > This too, but it's a small thing. > > >>>>>- I think variable names should be more verbose than $t > > > This is just cleanup. > > >>>>>- OMG, the logic in util_paginator.php is insane. Why is it that we >>>>>cannot construct a set of values with associated link values in the >>>>>core and remove all of that? >>>> >>>> >>>>Hey, i just ported the stuff, it was always there with one difference, >>>>i moved it in the UI logic related section. >>> >>>No argument about messy code; there is some messy code here and there, >>>and we can clean it up as we go, but I *do* have issue with putting this in >>>the realm of the templates - see below. >>> >>> >>>>>- Yeesh, util_message_list.php is just a little better, but why does >>>>>any of this have to be done in the template? >>>>> >>>> >>>> >>>>util_messages suppose to contain UI related logic that can be reused by >>>> other templates designers. Much of the UI related logic still in the >>>>.tpl files can be moved to the >>>>util_* files. >>> >>>I think it is a mistake to put at least half of those functions in the >>>template scope. If the goal is to be flexible for any template engine, >>>then we can't expect that all implementations will be able to use the >>>functions in those files so easily, if at all. Per my argument above, >>>anything that is merely calculating a number or other element that is >>>generic and is common to all templates should be simply done in core and >>>handed to the template class to greatly simplify the template's job. >>> >> >>I don't care where those UI related function are located. At this moment >>they are in the templates dir. The only thing I want to achieve is a >>strickt separation between SM core and SM UI. That means I DO NOT want >>function files in between the normal sm core function files that do UI >>related stuff like creating a paginator, calculating column width etc etc. > > > Absolutely. No argument here. This is where Fredrik's thoughts seem > applicable. I have long dreampt of a much more modular SM -- mostly > meaning that I'd really like to see the OO design and coding of the > delivery mechanisms completed and then do the same thing to all the > other applicable components. Right now, the API is a little hard to > grasp (although it is powerful and we shouldn't remove it all, just > make the more common actions easier to accomplish for anyone who wants > to use them -- plugins, core, or possibly an authorized 3rd party). > Um, where I am going with this is that I think the way page requests > are handled today, we are still really limited in our API - core calls > are litered all over the place - it's pretty ugly in some places. > It'd be really great if we could tell template developers that all > they have to do to get a concisely packaged list of X number of > messages for a message list is to merely call one function. Actually, > that call would be above the level of the template (in the middle > layer that Fredrik refers to), but I hope you can see what I am > getting at. Stuff like that might also help make SM WAP-able and > things like that too. > > So when I say I think all that logic is misplaced in the template > directory, I am NOT implying that we should litter the "core" with > those kinds of things. We agree that the two do not belong in the > same place. What I was implying is what Fredrik explicitly stated. > When I develop templated sites, my usual methodology is to create a > set of library files that offer an API. These files are in a separate > directory and define a core functionality that knows nothing about how > the data will be used. They just take requests and give some data > back. Then I have a set of front-line files that receive the page > requests, get the right data from the application library/API, and put > it together and make any lightweight changes dictated by the user > request. The templates aren't any part of this.... the templates then > merely take all the preprocessed data and SHOW it. They don't FIGURE > OUT anything. > > Really long answer, sorry for being so verbose. > > >>Find a better place where we can stuff those functions. The only condition >>is that the UI related functions files are kept together in a single >>directory, separated from the rest. > > > So I think we might all agree that we can create a "middle" layer > between core and template. The problem here is that I would suggest > that that layer should be the recipient of the page requests. I think > our code might not be ready for that yet. I'll have to look to see if > there is a good place to try it out. > > Actually, though, the separation between the src/ directory and the > functions/ and classes/ directories isn't so far off. The src/ files > just need a lot of work. :) And maybe a new directory name that is > more indicative of their purpose. > > To bring this back down to earth, I think the functions that I > originally asked about should be contained either in the src/ > directory or another directory intended to hold files with functions > that generate generic, non-template-specific display data. > > And following up on the discussion on the CVS list, I think the src/ > files should construct all translated strings and assign them to the > templates already translated. > > >>>>>- We probably need to figure out a place to have some centralized >>>>>documentation of all the variables handed to the template; some of >>>>>them are obvious, but some are a bit obscure (especially arrays/nested >>>>>arrays) >>>> >>>> >>>>>In general, I think one of the main goals in how we design the >>>>>templates is to make them as accessible as possible to designers and >>>>>other people who may be less skilled at any kind of programming. >>>>>Another obvious goal is >>>>>to keep the HTML code in one place, as sequential as possible, not >>>>>interspersed in logic and abstracted into other functions. I do not >>>>>think we have succeeded so far. Weeding out the HTML from the logic >>>>>in some of these places such as util_paginator.php is over the top and >>>>>will not encourage wide-spread "templatization", since only people who >>>>>are willing to dive in deep to that code will build templates. Also, >>>>>having to duplicate that logic for people building their own templates >>>>>from the ground up or in another template engine is too much to expect >>>>>I think, >>>>>especially if we can do a lot of that logic for them. >>>> >>>> >>>>I disagree a bit. SquirrelMail is complex with all the user options and >>>> the message list is probably the most complex part for templates. I >>>>think a template designer must have more skills then only html skills >>>>otherwise they are not capable for designing squirrelmail templates. >>> >>>Sure, but I think that's a little bit of a cop-out, when I think there >>>is more we can arguably do to simplify the templates. Calculating things >>>that have no direct interface implications should be done in core, even if >>>it is something like a list of page numbers and the pre-built links for >>>each page. The more easy to understand, the more popular and powerful SM >>>will become. >>> >>> >>>>I agree we must move some of the logic to the util files to make the >>>>current template less complex. >>> >>>I think we need to remove some more of the HTML that is buried in the >>>util files, and I think we need to push many of those util functions into >>>the core. >>> >> >>Make that the UI core, see my comments about separation above, > > > OK, I think we probably agree, so I didn't need to be so damn verbose > above. :-\ > > >>>>And once again, the util_* files are not templates but UI related logic >>>> files that shouldn't be touches by template designers so complexity in >>>> those files isn't a problem at all. >>> >>>So then they should be in the core. >> >>.... >>------------ >> >>To summarize, the discussion is about the amount of logic inside and >>outside the template and where that logic should be located. >> >>I think it should be easy to reduce complexity of current templates and >>probably it doesn't cost much time to simplify current templates. > > > Mmm, there is some heavy-duty weeding of HTML from PHP still in many > of the files, so I think it's a bigger job than that. But that does > not affect this discussion. > > >>The biggest task when moving to templates is NOT the template it self but >>adapting de underlying SM core and rip out all html and the removal of >>html generating functions. > > > I think BOTH are a big job and require a good amount of forethought. > Don't short-sell the presentation layer. That "middle" layer needs to > be well organized... and the more modular we can make it and the core > that it uses, the more powerful we will make SM! Yay! > > >>That's why I think we can proceed with adapting the rest of SquirrelMail >>and create templates in whatever form we want. I do not think we are >>finished when we have our first rough templates. When the first rough >>templates are ready, people should stand up and decide where to draw the >>line regarding the complexity of the template and create utility functions >>to simplify that logic. > > > I think I disagree. The organization of the "middle" or > "presentation" layer should be thought out, not thrown together > hodge-podge. That code is just as important as any other piece and > should not be treated like a second-class afterthought. That is what > creates the spaghetti that we currently suffer from in several places. > I don't think we are very far away from agreeing on something, so I > don't think it's a lot to ask for us to nail down some basic > architecture decisions before we get too far with the rest. > > >>Personally i'm interested in the first step till the rough templates are >>done. I'm not interested in the next step, creating the final templates. I >>think other people have more knowledge in that area. > > > I feel the same. I am not a designer. However, templating system > architecture IS something that WE have to get straight, and it is a > SEPARATE (and important) discussion from UI design. > > >>When we are done with cleaning up squirrelmail and work with templates the >>next step should take place. Move to a single entry page and get rid of >>frames. > > > Awww, I like frames. :-p > > Cheers, > > Paul Just like to say I've really enjoyed reading this conversation. Some great ideas here. Hope you don't mind if I chip in with some (extended) comments: The 3 layer approach: I think there was a broad agreement between Paul and Marc about this. Paul wanted the logic out of the UI files and into the 'core' (meaning at the time any part of the code not in the UI code). Marc wanted the logic out of the core and in a 'UI logic' section. A middle layer solves both desires. And it sounds like a great solution. It was mentioned that it was ok to expect the template designers to have a higher level of coding/logic competancy. You should really try to make things as simple as possible. The more UI designers the better the templates are going to be. The templates are the first visual impression a new user to squirrelmail is going to have. First impressions are VERY important and you want a few really stunning, first class templates to evolve. The easier the API -> the more UI developers -> the quicker we get some great designs. Javascript: I would suggest in the squirrelmail config. $template_name and $template_name_js. When javascript is detected the relevant template is loaded. This allows admins to choose an 'enhanced' template for js users and a basic one for when js is disabled. Much like gmail has it's two display versions. Designers can choose then whether they want to include js in their templates without having to worry about 'if javascript is on then do this otherwise do that'. Simpler for the designers thus more designs. You will have a library of templates, some of which require js and some don't. Obviously the designer can still choose to create a template that handles both situations - then both template variables can just be set to load the same template. There is another problem - I remember someone talking about creating a FLASH based template (!). What happens if the browser does not have flash installed? Should squirrelmail be able to detect this and load a non-flash alternative? Why not? Each template could have a function that checks if the browser environment is suitable for it to be loaded. If false the next in the preference list is used. Eg: ?->Flash->Javascript->HTML 2nd Layer Design: My gut feeling is this should be designed from the TOP-DOWN to make sure the API is optimised for the template designer. A bottom-up approach may result in the API and therefore designer being constrained. Think first about what the template designer wants to see. We should get some imput from experienced template designers. Plugins with UI Interaction: Sometimes plugins will add a whole new button to the UI. How will this be modified? Will templates have to be created with a "Supported Plugins" list? This would require template revisions after the creation of every new UI changing plugin. Smells bad. Should plugins have the ability to modify the template (kind of a two-way API)? This sounds too complex. I think the data exported through the 2nd layer should be divided into two parts. Core-provided data that is ALWAYS going to be consistent and Plugins-provided data that the template cannot depend on being present. I guess this will modify the plugins install process to: 1. Unzip plugin 2. Configure plugin (+patch anything if necessary) 3. View plugin's exported UI data. 4. Modify template to handle the plugin data. 5. Enable plugin. Step 4 could be quite onerous! For example imagine integrating the calender plugin. I don't however see another way just now unless we can somehow move this task to the plugin developer or the temaplate designer. The plugin developer shouldn't have to think about UI as that is going backwards by mixing logic and UI. The template designer shouldn't have to consider every single plugin and cannot possibly be expected to immediately release updates once a new plugin comes out. It has to be left to the mail admin to do the dirty work. Or does it? Define UI display groups: Examples: "Menubar", "Folder_list_top", "buttons_above_compose_area". These are all broadly based on the current hooks that are UI-related. When a plugin wants to add a UI element it exports it to one of these groups. The template designer can then code the template to make an intelligent guess of what to do given an element and a group. Eg it dislays all Core-provided links from the Menubar (Compose,Addresses,Folders etc) and if there are any Plugin-provided elements in this group it has a good idea where they should go (eg in another line under the main menu bar or in a drop down list at the end of the menubar etc). the display function could be something like: add_ui($display_group,$display_priority,$element_type,$display_value,$action_value) example: add_ui("Menubar","End","Button",_("Weather"),"SM_PATH.'/plugins/weather/show_weather.php'"); Daniel |
From: Paul L. <pa...@sq...> - 2005-11-25 21:35:04
|
> surprised to see that the mailbox_form_before, mailbox_index_before, and > mailbox_index_after hooks are left in the template. Off the top of my > head, I am not sure what plugins use those hooks and what they do, but I > am worried about two things here: > > - Non-PHP templates may or may not be able to run PHP hooks, or if they > can, they may not provide all of the global (and even non-global) > context and function call arguments that the hooks require. I do not > really like the idea of just dumping hooks as-is into the templates > without more thought about ways we can support hooks in templates no > matter the implementation. This is what I had tried to voice in > numerous emails previously, but I guess didn't really get through. Is > there anything anyone can think of to perhaps provide a different > hooking mechanism in the template class itself? At the very least, we > need to make sure the hooks left in the templates are being used for > plugins to spit out add-on HTML code, no more.... and that any context > they need is provided perhaps explicitly via mechanisms that are > extensible to other template paradigms. > > - In the case of subject_link hook, which does in fact just allow > plugins to add stuff to the <a> tag that encases the subject (most > commonly to add a target attribute). Even though it is a HTML add-on > hook, my inclination is NOT to put it in the template; instead put it > back in mailbox_display, where it can still enjoy the same access to > SM/PHP context without the above concerns and can simply add extra > information to whatever is put in the template (I think I will have to > add some kind of "extra link attributes" entry for the subject of each > message). It would be nice if we could pull all hooks back into the > core in this manner and then talk later about adding a different hook > mechanism (or even the same one, just with different, template-specific > hook names) for templates so that plugins can interact the same as they > always have with SM and differently with templates if they need to. Looking at mailbox_index_before, it is used by the fortune plugin to spit out a random fortune formatted with some simple HTML at the top of the message list. The preview_pane plugin spits out a button during the mailbox_index_after hook. The select_range plugin has more complicated needs for the mailbox_index_before hook, wherein it looks at things like how many messages are on the current mailbox listing. Some thoughts: - Aside from select_range, these hooks could remain in the template and just let the plugins dump out whatever HTML they wanted to. - select_range assumes a certain PHP context, which I think is either going to break or at the least is very bad design. If used as such, this hook should not be in the template. - If templates may have different formatting and style, then having a plugin dump out the same HTML in that hook may not work for just any template. It would be nice if the plugin put out only the actual content that needs to be displayed, but there isn't an easy way to communicate what its meaning is to the template (meaning implies formatting to the template), unless we created some kind of elaborate set of codes, which probably isn't a good idea. - If some template is radically change the page layout, having the hook in the template makes it very easy to change the location of the plugin output, however there is still the problem of the plugin spitting out some formatting that is not appropriate to the template. So what I think I am proposing is that all the hooks might be better off in the core. The core should make the current template object available to the plugins during the hook so they can add (assign) some predetermined HTML string to the template. The template can then do whatever it needs to/with that string. This gives plugins all the PHP/SquirrelMail context they have always expected (thus they are more powerful), and the templates have the flexibility to do what they want without worrying about how to execute hooks (although we still may want to talk about if it is worth it (or even possible) to design a different hooking mechanism for templates). The problem remains that formatting may not match up between the template and the plugin. The only solution I can think of beside some rediculous mini-template system for the plugins is to make sure the plugin has an easy way to determine what template is in use (create a core function such as sqgetCurrentTemplate), based upon which it can alter the formatting of its output if needed. That would require collaboration between plugin authors and template designers, which isn't horrible, although there may be a better solution out there - something that abstracts the output formatting of a plugin to a middle ground that is modifyable by template designers.... or something.... -paul |
From: Fredrik J. <sqm...@fi...> - 2006-01-30 10:34:33
|
> Hello Paul, > > > Thnx for the hint about the template discussion so let's continue. > > > > On Mon, November 28, 2005 8:39 am, Paul Lesneiwski wrote: > >> > >>>>> I finally got to open a template file and see that there is a >>>>> large amount of logic in there. I don't want to make rash >>>>> accusations, since logic in template files is not bad in and of >>>>> itself, and with the amount of things that we can do with SM, this >>>>> will probably not ever change that much.... I guess I just wanted >>>>> to voice a little concern that we make sure that all the logic is >>>>> strictly to make interface decisions. >>>> >>>> I looked a little closer at message_list.tpl today. I think that >>>> there is way too much logic in the "template": >>> >>> >>> Yes there is because it is NOT the final template. I.e., normally you= >>> use different templatete sets for js or non js templates which >>> reduces the logic a bit. The only goal of the "template" you were >>> looking at it seperating UI related logic from the rest. >> >> Are you suggesting that we should have a default template when js is >> detected/on and a different one for when it is unavailable/off? I'm n= ot >> sure we need to go that far. I'm also not sure that's the most >> important logic in question here. > > Yes I was suggesting that. > > >> >>>> - I don't see any reason why the section called 'Calculate string >>>> "Viewing message x to y (z total)"' can't be done in the core, where= >>>> the x y and z variables are calculated and handed to the template >>>> to be used as needed >>> >>> >>> It's UI related logic and it shouldn't be part of core. It's okay >>> that this kind of logic takes place in a file in the template >>> dorectory, see also how the paginator logic is separated . >> >> I disagree. I think that it is a fuzzy line between the two, and when= >> it comes to stuff like this -- logic that makes a template unecessaril= y >> complex -- I always do the math and logic in the core. In this case, >> if the core was given a starting message # and it has a size per page,= >> then it is not unreasonable to expect that it can calculate the other >> page and paginator details, such as what page we are on, the total >> number of pages, and the paginator numbers and associated links. >> >> None of those things has any interface implication that I can see. >> Calculating them in core only makes the template job easier and much >> more straight-forward. The template takes those numbers and links and= >> puts them into whatever format it needs. Template engines that are mo= re >> simplistic then won't have to stretch to implement things like this, >> and even designers using powerful template engines don't necessarily >> care about constructing page numbers and pagination information when a= ll >> they are doing is rearranging how those elements are shown. >> > > Okey, I agree that it probably makes more sense to calculate links > outside the template. > >>>> - I am not yet sure exactly why $aSortSupported is built in the >>>> template >>>> >>> >>> >>> Should be moved to the UI related logic section (util_*.php). >>> >>> >>> >>> >>>> - Many constants such as all the column constants and SM_PATH seem >>>> to be being accessed not via the template, which I think violates >>>> the template model >>>> >>>> - There should be a form_action instead of assuming php_self >>>> >>>> >>>> >>>> >>>> - I think variable names should be more verbose than $t >>>> >>>> >>>> >>>> >>>> - OMG, the logic in util_paginator.php is insane. Why is it that >>>> we cannot construct a set of values with associated link values in >>>> the core and remove all of that? >>> >>> >>> Hey, i just ported the stuff, it was always there with one >>> difference, i moved it in the UI logic related section. >> >> No argument about messy code; there is some messy code here and there,= >> and we can clean it up as we go, but I *do* have issue with putting th= is >> in the realm of the templates - see below. >> >>>> - Yeesh, util_message_list.php is just a little better, but why >>>> does any of this have to be done in the template? >>>> >>> >>> >>> util_messages suppose to contain UI related logic that can be reused >>> by other templates designers. Much of the UI related logic still in >>> the .tpl files can be moved to the >>> util_* files. >> >> I think it is a mistake to put at least half of those functions in the= >> template scope. If the goal is to be flexible for any template engine= , >> then we can't expect that all implementations will be able to use the >> functions in those files so easily, if at all. Per my argument above,= >> anything that is merely calculating a number or other element that is >> generic and is common to all templates should be simply done in core >> and handed to the template class to greatly simplify the template's jo= b. >> >> > > I don't care where those UI related function are located. At this momen= t > they are in the templates dir. The only thing I want to achieve is a > strickt separation between SM core and SM UI. That means I DO NOT want > function files in between the normal sm core function files that do UI > related stuff like creating a paginator, calculating column width etc > etc. > > Find a better place where we can stuff those functions. The only > condition is that the UI related functions files are kept together in a= > single directory, separated from the rest. > > <snip> > > >>>> - We probably need to figure out a place to have some centralized >>>> documentation of all the variables handed to the template; some of >>>> them are obvious, but some are a bit obscure (especially >>>> arrays/nested arrays) >>> >>> >>>> >>>> In general, I think one of the main goals in how we design the >>>> templates is to make them as accessible as possible to designers and= >>>> other people who may be less skilled at any kind of programming. >>>> Another obvious goal is >>>> to keep the HTML code in one place, as sequential as possible, not >>>> interspersed in logic and abstracted into other functions. I do >>>> not think we have succeeded so far. Weeding out the HTML from the >>>> logic in some of these places such as util_paginator.php is over the= >>>> top and will not encourage wide-spread "templatization", since only >>>> people who are willing to dive in deep to that code will build >>>> templates. Also, having to duplicate that logic for people building= >>>> their own templates from the ground up or in another template engine= >>>> is too much to expect I think, >>>> especially if we can do a lot of that logic for them. >>> >>> >>> I disagree a bit. SquirrelMail is complex with all the user options >>> and the message list is probably the most complex part for templates.= >>> I >>> think a template designer must have more skills then only html skills= >>> otherwise they are not capable for designing squirrelmail templates. >> >> Sure, but I think that's a little bit of a cop-out, when I think there= >> is more we can arguably do to simplify the templates. Calculating >> things that have no direct interface implications should be done in >> core, even if it is something like a list of page numbers and the >> pre-built links for each page. The more easy to understand, the more >> popular and powerful SM will become. >> >>> I agree we must move some of the logic to the util files to make the >>> current template less complex. >> >> I think we need to remove some more of the HTML that is buried in the >> util files, and I think we need to push many of those util functions >> into the core. >> > > Make that the UI core, see my comments about separation above, > > >>> And once again, the util_* files are not templates but UI related >>> logic files that shouldn't be touches by template designers so >>> complexity in those files isn't a problem at all. >> >> So then they should be in the core. >> > > .... > ------------ > > > To summarize, the discussion is about the amount of logic inside and > outside the template and where that logic should be located. > > I think it should be easy to reduce complexity of current templates and= > probably it doesn't cost much time to simplify current templates. > > The biggest task when moving to templates is NOT the template it self b= ut > adapting de underlying SM core and rip out all html and the removal of= > html generating functions. That's why I think we can proceed with adapt= ing > the rest of SquirrelMail and create templates in whatever form we want.= I > do not think we are finished when we have our first rough templates. Wh= en > the first rough templates are ready, people should stand up and decide > where to draw the line regarding the complexity of the template and cre= ate > utility functions to simplify that logic. > > Personally i'm interested in the first step till the rough templates ar= e > done. I'm not interested in the next step, creating the final templates= =2E I > think other people have more knowledge in that area. > > When we are done with cleaning up squirrelmail and work with templates > the next step should take place. Move to a single entry page and get ri= d > of frames. > > Regards, > > > Marc. I'm no software design wiz, but it's possible to use three or more layers= =2E First layer would be the core functionality; the second layer would be putting the data in some structure which is then passed to the third laye= r - the UI. gettext functions could be used in the second layer, which is used for preparing the data from the core to the UI. This would mean that= translations are provided by SquirrelMail and not the template engine, thus making it possible to provide translations the same way we do today.= If we want SquirrelMail to work with any templating system, we need to provide the first and second layer, the second layer being a well defined= API which the template engine can use. We also need to provide a default template system, so SquirrelMail can provide a UI included in the distribution, but any admin may choose to replace the third layer with th= e template engine of their choice. Or maybe I'm just misunderstanding the topic discussed in this thread. Shouldn't this discussion be on the DEVEL list instead of CVS list, by th= e way? I=92m posting my comment in this thread as well. Sorry for being redundan= t. Sincerely, Fredrik. |
From: Steve B. <sbr...@gm...> - 2006-01-30 17:46:13
|
> I'm no software design wiz, but it's possible to use three or more layers= . > First layer would be the core functionality; the second layer would be > putting the data in some structure which is then passed to the third laye= r > - the UI. gettext functions could be used in the second layer, which is > used for preparing the data from the core to the UI. This would mean that > translations are provided by SquirrelMail and not the template engine, > thus making it possible to provide translations the same way we do today. FWIW, I agree with this approach. I think there should be three layers: SQM Core layer, some type of UI-abstraction layer, and the UI itself. I'm not sure what form the abstraction layer will take (maybe just a bunch of functions?), but that can be discussed/debated in the coming weeks. I'm also concerned about the amount of logic needed in templates, but as Marc pointed out, the current templates are just step 1: achieving a (very) rough separation between UI and non-UI logic. My worry is that having too much logic in there is going to scare off potential template designers who aren't familiar w/ PHP. I've got some ideas on how this can all work, but I want to get everything into templates before we start separating the finer points of logic/UI. Steve |