On Mon, 16 Jan 2006 01:36:17 +0100, Paul Cantrell <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
