before-body, post-initialization: Those will do the trick, but seem to
me as the
easy way out (not necessarily bad). Another option is to add 3 optional
attributes
to body and initialization: id, before, after. Before and after can take
the '*' value,
just like hivemind implements this for services ordering.
shared script / parameter logic: I don't like .script sharing (but
that's probably
because we used bad naming in Tacos). More importantly however, i don't like
much javascript inside .script files. These files should have minimum js
code.
The goal is: nicer "View Source", much much shorter Ajax responses,
testability.
So, code reuse should happen inside the included (and static) js files.
parameters shared by many components: Extracting common interfaces helps
a lot here - just like Felix recently did in tacos.
Jesse Kuhnert wrote:
I'd like to get opinions / input on how to handle a few things.
The first is the addition of some new Script elements in the core script
dtd. In Tacos we had a definite need to apply pre - during - post
javascript
content to a response for things. The during part is handled by Script
already, and to some degree post is. I'd like to add in the following new
elements for now (until a better scenerio can be thought out)
- before-body - The naming will probably take a while to get right. This
element will hold content that is applied ~before~ any other js
content. It
will also serve as our ajax section for handling pre-effect sort of
operations. Uses for this would be:
1) Applying html effects before some content is changed
2) Doing things like hiding / showing a Dialog
3) ?
- post-initiliaztion - Initialization is still useful just the way it is,
but in some circumstances we're going to want certain operations to only
happen after all of the ~normal~ js has been run. I think this mostly
applies to forms right now but there may be other uses for it.
I won't add these new elements in until I actually need them to handle
some
specific operation, but wanted to plant the seed of thought for others to
speak on.
The other issue that would be nice to have solved is the handling of
shared
script / parameter logic that Tacos is doing. At first we had all the
script
files acting individually and there was a lot of code duplication. Now
a lot
of the script files are shared but it feels a little confusing looking at
them sometimes. Any ideas on how to share these component parameters /
script logic in an easier way are definitely welcome.
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
