tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <e...@ehatchersolutions.com>
Subject Re: Default binding prefixes
Date Thu, 31 Mar 2005 21:46:18 GMT
Maybe the idea of having default bindings per parameter isn't such a 
good idea then.   But, it sure is ugly to see this:

	listener="ognl:listeners.method" (3.0)
	listener="listener:method" (3.1)

Duplication drives me nuts!  But, I certainly see the confusion in 
making the change.

	Erik


On Mar 31, 2005, at 4:18 PM, Brian K. Wallace wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I can definitely see confusion mounting from this type of "default one
> way here and another way there" philosophy. Instead of "if I want to
> display X, use 'X'" it's "if I want to display X, use 'X' - unless I'm
> working in the page specification". Big fan here of "to do that, do 
> this
> every time" - keeps things simple.
>
> That said...
>
> I also see a deliniation of "HTML" vs "You've got a framework back
> there" development. In having a web designer perform their work, they
> should be able to default to their "native tongue" - literal values.
> This might help 'push' component/page configuration back into the
> specifications (which, for me, would re-emphasize the ability to have
> page files alongside the HTML as well as [read: either/or - not both]
> alongside the Java code). If this is clearly documented, it might
> actually prove beneficial to some saying "If I'm dealing with a spec, I
> _always_ do it this way. If I'm in the HTML, I _always_ do it that 
> way."
> Then for those needing more, you add in the "unless I want/need to do
> something else".
>
> End thought: I see the shortening of prefixes as a definite "good
> thing", but I see a definite need to document/educate if there are 
> going
> to be two different defaults depending only on whether you're in a 
> spec,
> or the plain HTML. To quote your statement "users have to be careful" -
> that's a sure sign of higher list activity forthcoming.
>
> Howard Lewis Ship wrote:
> | Didn't quite see this coming.
> |
> | The change *breaks* most existing code.
> |
> | For example:
> |
> | <html jwcid="@Shell" title="Private Assets">
> | <body jwcid="@Body">
> |
> | <img jwcid="@Image" image="asset:logo"/>
> |
> | </body>
> | </html>
> |
> |
> | Since title is a formal parameter of Shell, the value ("Private
> | Assets") is treated as an OGNL expression, not a literal.
> |
> | I think the rules get more complicated:
> |
> | - Informal parameters in HTML templates should default to "literal"
> | - Informal parameters in spec should default to "ognl"
> | - Formal parameters which do not explicitly define a prefix should
> | default as with informal parameters
> | - Formal parameters that explicitly define a default prefix should
> | override the meta-default ("literal", or "ognl", depending on
> | location).
> |
> | Once we apply these rules, we should be able to convert the template 
> to:
> |
> |
> | <html jwcid="@Shell" title="Private Assets">
> | <body jwcid="@Body">
> |
> | <img jwcid="@Image" image="logo"/>
> |
> | </body>
> | </html>
> |
> | ... after changing the Image component's image parameter's
> | default-binding to "asset".  More dramatic gains elsewhere.
> |
> | Remember also that in any 3.0 specification, the element (<binding>,
> | <message-binding>, <static-binding>) will implcitly use a prefix
> | ("ognl", "message", "literal"). So for 3.0 DTDs there shouldn't be 
> any
> | ambiguity.  For 3.1, users have to be careful using a value without a
> | "literal:" prefix, since it may be interpreted differently depending
> | on the parameter.
> |
> |
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (MingW32)
>
> iD8DBQFCTGlAaCoPKRow/gARAkYVAJ9f1plG9jf+kZuwiZWqaRN+Hax6NgCfTfuM
> HDJcikgOHEKzH1p6WUNE6zI=
> =pCzB
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


Mime
View raw message