You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Martin Strand <ma...@entcap.se> on 2006/01/15 15:15:21 UTC
simplification?
How about using <component> attributes instead of the <binding> element?
i.e. we would have
<component id="loop" type="For" source="ognl:someCollection"/>
instead of
<component id="loop" type="For">
<binding name="source" value="ognl:someCollection"/>
</component>
The old way would still work, but there would be a simplified alternative.
What do you think?
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: simplification?
Posted by Gregg Bolinger <ta...@gmail.com>.
The simplified alternative is to use annotations if you can. Otherwise, I
don't see much benefit in the new syntax.
Gregg
On 1/15/06, Martin Strand <ma...@entcap.se> wrote:
>
> How about using <component> attributes instead of the <binding> element?
> i.e. we would have
>
> <component id="loop" type="For" source="ognl:someCollection"/>
>
> instead of
>
> <component id="loop" type="For">
> <binding name="source" value="ognl:someCollection"/>
> </component>
>
> The old way would still work, but there would be a simplified alternative.
> What do you think?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
Re: simplification?
Posted by Alan Chandler <al...@chandlerfamily.org.uk>.
On Sunday 15 January 2006 14:15, Martin Strand wrote:
> How about using <component> attributes instead of the <binding> element?
> i.e. we would have
>
> <component id="loop" type="For" source="ognl:someCollection"/>
>
> instead of
>
> <component id="loop" type="For">
> <binding name="source" value="ognl:someCollection"/>
> </component>
>
I have to say I always use what I regard as a much simpler alternative.
1) I never have .page files, and only .jwc files when there is not need of a
java class to do anything in the component (otherwise I just annotate the
java class)
2) I always include as much as I can in the tempate file - I find refering out
to another specification file a real pain in trying to understand what is
going on.
Therefore what you are doing above, I would always do as
In the template
<span jwcid="@For" source="ognl:someCollection" value="ognl:someObject" >
...
<span jwcid="@Insert" value="ognl:someObject.someField">Text </span>
(or any other sort of text)
</span>
And in the java file
public abstract void setSomeCollection( List<MyObject> l);
and
public void pageBeginRender (PageEvent event) {
if (!event.getRequestCycle().isRewinding()) {
setSomeCollection( --- got from wherever);
...
}
}
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: simplification?
Posted by Paul Cantrell <ca...@pobox.com>.
On Jan 15, 2006, at 7:22 PM, Martin Strand wrote:
> On Mon, 16 Jan 2006 01:36:17 +0100, Paul Cantrell
> <ca...@pobox.com> wrote:
>> (1) Make component infer the type from the return type of the
>> getter. It is just silly that I have to say "TextField" twice in a
>> row:
>>
>> @Component( type = "TextField" )
>> public abstract TextField getEmail();
>
> There is not a one-to-one mapping between Java types and component
> types. You can have two different components using the same
> TextField class, but with different .html templates and
> different .jwc files.
Fair enough, but in such situations, one would have to use the
explicit type="..." declaration, which seems quite reasonable.
The thing is, that's a less common case. Sacrificing simplicity in
the common case to accommodate the unusual does not seem like the
Tapestry Way!
Even the naive algorithm that takes the unqualified name of the Java
class and looks it up as a component name would make the type="..."
unnecesssary in 90% of cases.
> If we eliminated the .page/.jwc files completely, that would no
> longer be the case, since Tapestry would then always determine the
> Java type automatically for each component...
I'd love to make the .jwc files completely optional, as Tapestry has
already done with .page. Admittedly, this is a hard problem.
Cheers,
Paul
_________________________________________________________________
Piano music podcast: http://inthehands.com
Other interesting stuff: http://innig.net
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: simplification?
Posted by Martin Strand <ma...@entcap.se>.
On Mon, 16 Jan 2006 01:36:17 +0100, Paul Cantrell <ca...@pobox.com>
wrote:
> I have two simplifications in mind:
>
> (1) Make component infer the type from the return type of the getter. It
> is just silly that I have to say "TextField" twice in a row:
>
> @Component( type = "TextField" )
> public abstract TextField getEmail();
>
> (Howard, is there a compelling reason for this? There must be, but I
> don't see it.)
>
There is not a one-to-one mapping between Java types and component types.
You can have two different components using the same TextField class, but
with different .html templates and different .jwc files.
If we eliminated the .page/.jwc files completely, that would no longer be
the case, since Tapestry would then always determine the Java type
automatically for each component... unless two different namespaces would
use the same "org.apache.tapestry.component-class-packages", then you
could still have two different components mapped to the same Java type.
Does anyone have a clever solution to this? Using Java types instead of
component/page names would really ease refactoring.
> (2) There should be a naming convention that a getter named
> getXyzComponent() takes its value from the xyz property, and has a
> component ID of "xyz" instead of "xyzComponent." Then I could do this:
>
> <input jwcid="email">
>
> @Component
> public abstract TextField getEmailComponent();
> public abstract String getEmail();
> public abstract void setEmail(String email);
>
> Ahh! How nice. I could only wish.
>
> The current syntax for the above is full of irritating redundancy:
>
> <input jwcid="email">
>
> @Component(
> type="TextField",
> id="email",
> bindings="value=ognl:email" )
> public abstract TextField getEmailComponent();
> public abstract String getEmail();
> public abstract void setEmail(String email);
>
> Bleah.
>
> FWIW, I don't find that the annotations make the source file very messy
> at all. Maybe it's just because Eclipse's syntax highlighting and code
> folding do reasonable things with them? I certainly find them much more
> readable than XML config. Certainly they're much more concise!
>
Indeed they're more concise, but with 20 components on a page you'll need
20 getters with a 4-6 line @Component annotation for each one. I still
prefer to extract the component binding part from my Java source and put
it in a .page file instead. :)
--Martin
> Cheers,
>
> Paul
>
>
> On Jan 15, 2006, at 1:11 PM, Martin Strand wrote:
>
>> Personally, I hardly ever use the @Component annotation cause it makes
>> the source file so messy. And I try to include as little logic as
>> possible in the .html template. After all, the html vs logic separation
>> is one of Tapestry's greatest benefits IMO.
>> If the annotations would be simplified further, perhaps I would start
>> using @Component. I just can't think of any particular simplification,
>> what did you have in mind?
>>
>> On Sun, 15 Jan 2006 18:33:53 +0100, Paul Cantrell <ca...@pobox.com>
>> wrote:
>>
>>> The reason you can't do this in the page file is that it would make it
>>> impossible to have a meaningful DTD. Of course, you can do essentially
>>> the same thing in your HTML:
>>>
>>> <span jwcid="loop" source="ognl:someCollection>
>>>
>>> Ultimately, Gregg is right: annotations are the wave of the future.
>>> (Personally, I view .page and .jwc files as heading for deprecation,
>>> though the Tapestry team might not agree.) And I do think there are
>>> many things about Tapestry's annotation structure that could be
>>> simplified -- so that's where simplification efforts should be
>>> directed, IMO.
>>>
>>> Cheers,
>>>
>>> Paul
>>>
>>> On Jan 15, 2006, at 8:15 AM, Martin Strand wrote:
>>>
>>>> How about using <component> attributes instead of the <binding>
>>>> element?
>>>> i.e. we would have
>>>>
>>>> <component id="loop" type="For" source="ognl:someCollection"/>
>>>>
>>>> instead of
>>>>
>>>> <component id="loop" type="For">
>>>> <binding name="source" value="ognl:someCollection"/>
>>>> </component>
>>>>
>>>> The old way would still work, but there would be a simplified
>>>> alternative. What do you think?
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: simplification?
Posted by Paul Cantrell <ca...@pobox.com>.
I have two simplifications in mind:
(1) Make component infer the type from the return type of the getter.
It is just silly that I have to say "TextField" twice in a row:
@Component( type = "TextField" )
public abstract TextField getEmail();
(Howard, is there a compelling reason for this? There must be, but I
don't see it.)
(2) There should be a naming convention that a getter named
getXyzComponent() takes its value from the xyz property, and has a
component ID of "xyz" instead of "xyzComponent." Then I could do this:
<input jwcid="email">
@Component
public abstract TextField getEmailComponent();
public abstract String getEmail();
public abstract void setEmail(String email);
Ahh! How nice. I could only wish.
The current syntax for the above is full of irritating redundancy:
<input jwcid="email">
@Component(
type="TextField",
id="email",
bindings="value=ognl:email" )
public abstract TextField getEmailComponent();
public abstract String getEmail();
public abstract void setEmail(String email);
Bleah.
FWIW, I don't find that the annotations make the source file very
messy at all. Maybe it's just because Eclipse's syntax highlighting
and code folding do reasonable things with them? I certainly find
them much more readable than XML config. Certainly they're much more
concise!
Cheers,
Paul
On Jan 15, 2006, at 1:11 PM, Martin Strand wrote:
> Personally, I hardly ever use the @Component annotation cause it
> makes the source file so messy. And I try to include as little
> logic as possible in the .html template. After all, the html vs
> logic separation is one of Tapestry's greatest benefits IMO.
> If the annotations would be simplified further, perhaps I would
> start using @Component. I just can't think of any particular
> simplification, what did you have in mind?
>
> On Sun, 15 Jan 2006 18:33:53 +0100, Paul Cantrell
> <ca...@pobox.com> wrote:
>
>> The reason you can't do this in the page file is that it would
>> make it impossible to have a meaningful DTD. Of course, you can do
>> essentially the same thing in your HTML:
>>
>> <span jwcid="loop" source="ognl:someCollection>
>>
>> Ultimately, Gregg is right: annotations are the wave of the
>> future. (Personally, I view .page and .jwc files as heading for
>> deprecation, though the Tapestry team might not agree.) And I do
>> think there are many things about Tapestry's annotation structure
>> that could be simplified -- so that's where simplification efforts
>> should be directed, IMO.
>>
>> Cheers,
>>
>> Paul
>>
>> On Jan 15, 2006, at 8:15 AM, Martin Strand wrote:
>>
>>> How about using <component> attributes instead of the <binding>
>>> element?
>>> i.e. we would have
>>>
>>> <component id="loop" type="For" source="ognl:someCollection"/>
>>>
>>> instead of
>>>
>>> <component id="loop" type="For">
>>> <binding name="source" value="ognl:someCollection"/>
>>> </component>
>>>
>>> The old way would still work, but there would be a simplified
>>> alternative. What do you think?
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: tapestry-user-
>>> help@jakarta.apache.org
>>>
>>>
>>
>> _________________________________________________________________
>> Piano music podcast: http://inthehands.com
>> Other interesting stuff: http://innig.net
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user-
>> help@jakarta.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
_________________________________________________________________
Piano music podcast: http://inthehands.com
Other interesting stuff: http://innig.net
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: simplification?
Posted by Martin Strand <ma...@entcap.se>.
Personally, I hardly ever use the @Component annotation cause it makes the
source file so messy. And I try to include as little logic as possible in
the .html template. After all, the html vs logic separation is one of
Tapestry's greatest benefits IMO.
If the annotations would be simplified further, perhaps I would start
using @Component. I just can't think of any particular simplification,
what did you have in mind?
On Sun, 15 Jan 2006 18:33:53 +0100, Paul Cantrell <ca...@pobox.com>
wrote:
> The reason you can't do this in the page file is that it would make it
> impossible to have a meaningful DTD. Of course, you can do essentially
> the same thing in your HTML:
>
> <span jwcid="loop" source="ognl:someCollection>
>
> Ultimately, Gregg is right: annotations are the wave of the future.
> (Personally, I view .page and .jwc files as heading for deprecation,
> though the Tapestry team might not agree.) And I do think there are many
> things about Tapestry's annotation structure that could be simplified --
> so that's where simplification efforts should be directed, IMO.
>
> Cheers,
>
> Paul
>
> On Jan 15, 2006, at 8:15 AM, Martin Strand wrote:
>
>> How about using <component> attributes instead of the <binding> element?
>> i.e. we would have
>>
>> <component id="loop" type="For" source="ognl:someCollection"/>
>>
>> instead of
>>
>> <component id="loop" type="For">
>> <binding name="source" value="ognl:someCollection"/>
>> </component>
>>
>> The old way would still work, but there would be a simplified
>> alternative. What do you think?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
>
> _________________________________________________________________
> Piano music podcast: http://inthehands.com
> Other interesting stuff: http://innig.net
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: simplification?
Posted by Paul Cantrell <ca...@pobox.com>.
The reason you can't do this in the page file is that it would make
it impossible to have a meaningful DTD. Of course, you can do
essentially the same thing in your HTML:
<span jwcid="loop" source="ognl:someCollection>
Ultimately, Gregg is right: annotations are the wave of the future.
(Personally, I view .page and .jwc files as heading for deprecation,
though the Tapestry team might not agree.) And I do think there are
many things about Tapestry's annotation structure that could be
simplified -- so that's where simplification efforts should be
directed, IMO.
Cheers,
Paul
On Jan 15, 2006, at 8:15 AM, Martin Strand wrote:
> How about using <component> attributes instead of the <binding>
> element?
> i.e. we would have
>
> <component id="loop" type="For" source="ognl:someCollection"/>
>
> instead of
>
> <component id="loop" type="For">
> <binding name="source" value="ognl:someCollection"/>
> </component>
>
> The old way would still work, but there would be a simplified
> alternative. What do you think?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
_________________________________________________________________
Piano music podcast: http://inthehands.com
Other interesting stuff: http://innig.net
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: simplification?
Posted by Geoff Longman <gl...@gmail.com>.
More than just Spindle. It would kill any XML editor.
Geoff
On 1/15/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> I had thought about it, but it would mean abandoning the use of a DTD
> for the specs; it gave Geoff (Mr. Spindle) a near stroke when I
> mentioned it.
>
> On 1/15/06, Martin Strand <ma...@entcap.se> wrote:
> > How about using <component> attributes instead of the <binding> element?
> > i.e. we would have
> >
> > <component id="loop" type="For" source="ognl:someCollection"/>
> >
> > instead of
> >
> > <component id="loop" type="For">
> > <binding name="source" value="ognl:someCollection"/>
> > </component>
> >
> > The old way would still work, but there would be a simplified alternative.
> > What do you think?
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
>
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work. http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
--
The Spindle guy. http://spindle.sf.net
Get help with Spindle:
http://lists.sourceforge.net/mailman/listinfo/spindle-user
Blog: http://jroller.com/page/glongman
Feature Updates: http://spindle.sf.net/updates
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: simplification?
Posted by Howard Lewis Ship <hl...@gmail.com>.
I had thought about it, but it would mean abandoning the use of a DTD
for the specs; it gave Geoff (Mr. Spindle) a near stroke when I
mentioned it.
On 1/15/06, Martin Strand <ma...@entcap.se> wrote:
> How about using <component> attributes instead of the <binding> element?
> i.e. we would have
>
> <component id="loop" type="For" source="ognl:someCollection"/>
>
> instead of
>
> <component id="loop" type="For">
> <binding name="source" value="ognl:someCollection"/>
> </component>
>
> The old way would still work, but there would be a simplified alternative.
> What do you think?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org