John McNally wrote:
> I am not quite sure yet how Rafal's layout handles a navigation templates
> requirements regarding <head> content.
You are right, my solution takes away the possibility of manipulating head elements
from the navigations. On the other hand, I really couldn't think of any significant
reasons for navigations to do that. Title, and meta information should be generated
by screen class/template and/or layout template. CSS and JS libraries should be
specified by layout template. The main concern here is JavaScript. I think that
generaly, navigations should contain dynamically generated calls to functions that
are defined in external JS library files. Sometimes they need also to initailize
some global variables (like data structures for the library fuctions to chew on).
These don't need to be placed in head section to work. All the JS code that is placed
in global scope will get executed as page loading proceeds. The only problem I could
think of right now is adding tokens to onLoad attribute of <body>. I believe it's
possible, and probably better to handle initialization is a single page-wide method.
This method could use an array of function names it should call using eval(). This
array would be filled by method calls in global context that happen during page
loading.
> Beyond that and not really relevant here, ECS can be useful for form field
> generation. A Select with multiple items being initially selected, for
> example, is trivial to build with ECS. You can do it with a template as
> well, but I don't think it adds much. It is still probably going to have to
> be coded by an engineer, so in my mind the details should be hidden from the
> designer.
Sure, it may be handy to generate some markup inside screen class, and place
it into the context as a single entity. Still, building a select you are
mentioning is no less trivial using ebeded html that it is with ECS, and
I believe that the resulting code will be about the same pretty either ways.
But every programer may chose for him/herself of course. I just wanted to
move ECS out of my way during buliding layout.
> You are correct. I still do not like placing the Navigation adaptor object
> that is in the Layout context into a context available for navigations and
> screens. It should be possible to build a dynamic layout without combining
> the layout's context with that for the navs and screen.
I don't understand the problem of navigation adapter being available in these
contexts. Screen/navigation templates don't use it. And if they wanted to use it
for some reason (which is a bad idea), they could write screen/navigation class
that would put an instace of WebMacroNavigation into the context they use.
You can not prevent them from doing this, and using multiple contexts is in my opinion
an unnecessary complication.
Regards, Rafal
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
