How about using <componentattributes instead of the <bindingelement?
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 (AT) jakarta (DOT) apache.org
For additional commands, e-mail: tapestry-user-help (AT) jakarta (DOT) apache.org

The simplified alternative is to use annotations if you can. , I
don't see much benefit in the new syntax.

Gregg

1/15/06, Martin Strand <martin.strand (AT) entcap (DOT) sewrote:

How about using <componentattributes instead of the <bindingelement?
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 (AT) jakarta (DOT) apache.org
For additional commands, e-mail: tapestry-user-help (AT) jakarta (DOT) apache.org
--

The reason you can't do this in the page file is that it would make
it impossible to have a meaningful DTD. 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, IM

Cheers,

Paul

Jan 15, 2006, at 8:15 AM, Martin Strand wrote:

How about using <componentattributes 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 (AT) jakarta (DOT) apache.org
For additional commands, e-mail: tapestry-user-help (AT) jakarta (DOT) apache.org
--

Piano music podcast: http://inthehands.com
interesting stuff: http://innig.net

To unsubscribe, e-mail: tapestry-user-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: tapestry-user-help (AT) jakarta (DOT) apache.org

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 IM
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?

Sun, 15 Jan 2006 18:33:53 +0100, Paul Cantrell <cantrell (AT) pobox (DOT) 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. 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, IM

Cheers,

Paul

Jan 15, 2006, at 8:15 AM, Martin Strand wrote:
>
>How about using <componentattributes instead of the <bindingelement?
>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 (AT) jakarta (DOT) apache.org
>For additional commands, e-mail: tapestry-user-help (AT) jakarta (DOT) apache.org
>>
>>
>

Piano music podcast: http://inthehands.com
interesting stuff: http://innig.net
>
>
>

To unsubscribe, e-mail: tapestry-user-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: tapestry-user-help (AT) jakarta (DOT) apache.org
--

To unsubscribe, e-mail: tapestry-user-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: tapestry-user-help (AT) jakarta (DOT) apache.org

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

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 IM
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?

Sun, 15 Jan 2006 18:33:53 +0100, Paul Cantrell
<cantrell (AT) pobox (DOT) comwrote:
>
>The reason you can't do this in the page file is that it would
>make it impossible to have a meaningful DTD. 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, IM
>>
>Cheers,
>>
>Paul
>>
>Jan 15, 2006, at 8:15 AM, Martin Strand wrote:
>>
How about using <componentattributes 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 (AT) jakarta (DOT) apache.org
For additional commands, e-mail: tapestry-user-
help (AT) jakarta (DOT) apache.org


>>
>
>Piano music podcast: http://inthehands.com
>interesting stuff: http://innig.net
>>
>>
>>
>
>To unsubscribe, e-mail: tapestry-user-unsubscribe (AT) jakarta (DOT) apache.org
>For additional commands, e-mail: tapestry-user-
>help (AT) jakarta (DOT) apache.org
>>
>>
>
>
>

To unsubscribe, e-mail: tapestry-user-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: tapestry-user-help (AT) jakarta (DOT) apache.org
--

Piano music podcast: http://inthehands.com
interesting stuff: http://innig.net

To unsubscribe, e-mail: tapestry-user-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: tapestry-user-help (AT) jakarta (DOT) apache.org

Mon, 16 Jan 2006 01:36:17 +0100, Paul Cantrell <cantrell (AT) pobox (DOT) 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 "", 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. :)

Cheers,

Paul
--
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 IM
>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?
>>
>Sun, 15 Jan 2006 18:33:53 +0100, Paul Cantrell <cantrell (AT) pobox (DOT) 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. 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, IM

Cheers,

Paul

Jan 15, 2006, at 8:15 AM, Martin Strand wrote:

How about using <componentattributes 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 (AT) jakarta (DOT) apache.org
For additional commands, e-mail: tapestry-user-help (AT) jakarta (DOT) apache.org

Jan 15, 2006, at 7:22 PM, Martin Strand wrote:
Mon, 16 Jan 2006 01:36:17 +0100, Paul Cantrell
<cantrell (AT) pobox (DOT) comwrote:
>(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
interesting stuff: http://innig.net

To unsubscribe, e-mail: tapestry-user-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: tapestry-user-help (AT) jakarta (DOT) apache.org