I like it, but after reading Stevey's latest blog entry today -
combined with recent ognl stuff I've started getting fanciful ideas
that we could make this work for both sides of the argument. (link
http://steve-yegge.blogspot.com/2007/01/pinocchio-problem.html )
It seems that according to Steve you are already well on your way
towards building a system that "isn't crap" (except for the part where
you used java). It doesn't need re-booting. It is modular / extensible
/ pluggable / has a sort of form of advice / etc.. A kind of potential
qwan is forming if you will.. ;)
So anyways the idea is that there really isn't any good reason why the
system couldn't learn / figure out which kind of binding you meant for
XX% (i'd throw a number in but it'd obviously be arbitrary and mostly
based on T4 knowledge ) of the common cases.
Should there be some very extenuating circumstances the binding:
prefix logic can come in as a last resort. Sort of like how dynamic
languages treat variables and such?
The method of figuring it out would have to change depending on
context and a whole set of other rules of course, but with proper care
and ability it should be able to figure this out. I mean after all,
java is a static language right?
"user.role.description" Could first hunt in the most immediate
container for a user property ...Failing that start to flow up / out
and go for more general things like property key's, whatever else you
have cooking up your sleeve in T5.
Even with all of the varying choices of "where" something could be
coming from the algorithms for figuring that out should be greatly
helped by knowing where it's going "to". Since you are already able to
detect changes to files and these strings the cost of performing these
smart path resolutions would be much lower than if you had to randomly
figure them out for each and every page load. (as in T4)
What do you think? I might be interested in helping my idea form into
something real if it'll help ...Just to see if it's possible...Then
neither developer nor "user" would really have to do much work
managing these prefixes..
Of course - the sticky parts would come in when trying to make this
same dynamic discovery system work for people wanting to contribute
their own "bindings" / logic..But your system is already modular /
extensible / etc, so there's no reason why the dynamic binding stuff
shouldn't be as well.
On 1/17/07, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
I've checked these changes into the branch. I'm very happy with them,
the HTML is getting simpler and simpler.
Here's an example form:
<form t:type="Form">
<t:comp type="Errors"/>
<label t:type="Label" for="email">This isn't used</label>: <input
t:type="TextField" t:id="email" value="incident.email"
size="50" t:validate="required"/>
<br/>
<label t:type="Label" for="message"/>: <textarea
t:type="TextArea" t:id="message" t:label="Incident Message"
value="incident.message" cols="50" rows="10"
t:validate="required"> You can put text here, but it isn't used.
</textarea>
<br/>
<input t:type="Checkbox" t:id="urgent" value="incident.urgent"/>
<label t:type="Label" for="urgent"/>
<br/>
<input type="submit"/>
</form>
I kind of used all the options here. All the Tapestry specific
parameters are bound using the t: namespace. Thus:
t:validate="required" not t:validate="validate:required"
t:label="Incident Message" not t:label="literal:Incident Message"
t:for="email" not t:for="component:email"
I like the succinctness.
Yes, for a new component, you'll find that you need to "feel out"
which parameters need a prefix and which don't .... but I think that
it'll be natural. All I've been doing is saying: "if 99.9% of the
time, you would use prefix xxx: on that parameter, make xxx: be the
default binding prefix for that parameter". Thus Label's for
parameter is almost always going to be another component, so
"component:" is the default binding prefix.
The question is ... how to proceed from here? Dump it into the trunk?
Let is simmer in the branch a bit longer? Abandon the idea and run
screaming? Feedback please!
--
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jesse Kuhnert
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
