You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by "Newcomb, Michael P." <MN...@tacintel.com> on 2005/02/10 20:31:43 UTC
XDoclet
I just wanted to let the Tapestry users know that I have added Tapestry tag
support to XDoclet (xdoclet.sourceforge.net). You can now do things like:
/**
* @tapestry.page-specification description="a description"
*
* @tapestry.property name="displayName" value="My Cool Page"
*
* @tapestry.component id="e" type="Foreach"
* @tapestry.binding component="e" name="value" expression="names"
*
* @tapestry.component id="link" type="PageLink"
* @tapestry.binding component="link" name="page" expression="name"
* @tapestry.binding component="link" name="disabled"
* expression="disabledPageLink"
*/
public class MyPage
extends BasePage
{
...
}
and it will auto-generate your MyPage.page file.
Anyway, I have found it useful to manage my .page/jwc file from inside my
.java file.
Thanks,
Michael
RE: XDoclet
Posted by Naeem Malik <na...@btinternet.com>.
Any changes in this area are likely to affect my use of Tapestry so here
are my thoughts.
I can imagine users not wanting to create a .jwc xml file simply to
define properties or parameters for a page/component if they have
already created a custom Java class for the page/component.
Equally, I wouldn't want to have to create a new Java class for a
page/component simply to define a property or parameter for the
page/component. I can currently create many complex components without
having to explicitly create Java classes.
Additionally, the xml page/component specification allows Tapestry to
extended in many ways. For example, I use the specification extension
mechanism (ISpecificationResolverDelegate) to dynamically generate
specifications and achieve 'template inheritance' (creating a new
template based on an existing on). This is exactly the functionality
that Tiles provides and was needed for my project. The xml format for
specifications made implementing 'template inheritance' a trivial job.
Hope this helps,
Naeem Malik
-----Original Message-----
From: Howard Lewis Ship [mailto:hlship@gmail.com]
Sent: 11 February 2005 18:23
To: Tapestry users
Subject: Re: XDoclet
Mostly stuff on getters (and perhaps settters):
@Persist("session")
public abstract String getMyProperty();
@Inject("service:mymodule.MyHiveMindService")
public abstract MyHiveMindService getMyService();
@InjectState("visit")
public abstract Visit getVisit();
@Component("fred")
public abstract Fred getFred();
// Expose component 'fred' as property 'fred'
// Also:@Asset, @Bean
There may also be some value for defining assets and beans, even
components, as class annotations.
On Thu, 10 Feb 2005 19:13:59 -0500, Erik Hatcher
<er...@ehatchersolutions.com> wrote:
> Whether XDoclet or annotations - please everyone contemplating or
> implementing such things keep MVC in mind. There is a very good
reason
> to have glue between a Java class and the HTML template and blurring
> these things together is a slippery slope into ugliness. Tapestry
3.0,
> though, does have leakage where the awkward abstract methods come into
> play and must match <property-specification>'s. In fact, I've been
> using get/setProperty() exclusively lately and not doing the
'abstract'
> thing.
>
> With page classes moving towards POJO's with Tapestry and HiveMind
> having the smarts to wire things together, XDoclet usage would be
> pointless. Maybe the same would be the case with annotations too.
>
> Howard - what kinds of annotations are you thinking make sense in Java
> classes?
>
> Erik
>
>
> On Feb 10, 2005, at 3:29 PM, Howard Lewis Ship wrote:
>
> > I'm also looking forward to creating a Tapestry add-on based on JDK
> > 1.5 that would use annotations to substitute for all, or some of,
the
> > XML page specification.
> >
> >
> > On Thu, 10 Feb 2005 15:14:13 -0500, Erik Hatcher
> > <er...@ehatchersolutions.com> wrote:
> >> When I first came to Tapestry, I was doing Struts and EJB
development
> >> where we had a lot of XDoclet going on - in fact I built the
> >> <strutsvalidationxml> subtask in XDoclet because of the duplication
we
> >> were encountering.
> >>
> >> At first I thought using XDoclet to do exactly what you've done
made a
> >> lot of sense. After using Tapestry for a while I realized that
there
> >> is a pretty clean separation of concerns and that XDoclet would
only
> >> make a mess of things. To do XDoclet templating/subtasks very
nicely
> >> you have to really think through things a lot. For example - what
if
> >> I
> >> want an abstract property specification getter... the XDoclet
> >> infrastructure should recognize that either automatically or by an
> >> @tag
> >> on the getter to generate the <property-specification> element.
> >> Otherwise, if you specify the whole .page information in the class
> >> header javadoc you will inevitably be duplicating yourself
somewhere.
> >> I view XDoclet as a nice solution to some ugly problems, and don't
> >> feel
> >> Tapestry suffers from those ugly DRY (don't repeat yourself)
> >> violations
> >> out there.
> >>
> >> I do applaud Michael for doing this - it'll help "sell" Tapestry to
> >> shops that are entrenched in the XDoclet mindset.
> >>
> >> Erik
> >>
> >>
> >> On Feb 10, 2005, at 2:31 PM, Newcomb, Michael P. wrote:
> >>
> >>> I just wanted to let the Tapestry users know that I have added
> >>> Tapestry tag
> >>> support to XDoclet (xdoclet.sourceforge.net). You can now do
things
> >>> like:
> >>>
> >>> /**
> >>> * @tapestry.page-specification description="a description"
> >>> *
> >>> * @tapestry.property name="displayName" value="My Cool Page"
> >>> *
> >>> * @tapestry.component id="e" type="Foreach"
> >>> * @tapestry.binding component="e" name="value" expression="names"
> >>> *
> >>> * @tapestry.component id="link" type="PageLink"
> >>> * @tapestry.binding component="link" name="page"
expression="name"
> >>> * @tapestry.binding component="link" name="disabled"
> >>> * expression="disabledPageLink"
> >>> */
> >>> public class MyPage
> >>> extends BasePage
> >>> {
> >>> ...
> >>> }
> >>>
> >>> and it will auto-generate your MyPage.page file.
> >>>
> >>> Anyway, I have found it useful to manage my .page/jwc file from
> >>> inside
> >>> my
> >>> .java file.
> >>>
> >>> Thanks,
> >>> Michael
> >>>
> >>
> >>
---------------------------------------------------------------------
> >> 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
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: XDoclet
Posted by Howard Lewis Ship <hl...@gmail.com>.
Mostly stuff on getters (and perhaps settters):
@Persist("session")
public abstract String getMyProperty();
@Inject("service:mymodule.MyHiveMindService")
public abstract MyHiveMindService getMyService();
@InjectState("visit")
public abstract Visit getVisit();
@Component("fred")
public abstract Fred getFred();
// Expose component 'fred' as property 'fred'
// Also:@Asset, @Bean
There may also be some value for defining assets and beans, even
components, as class annotations.
On Thu, 10 Feb 2005 19:13:59 -0500, Erik Hatcher
<er...@ehatchersolutions.com> wrote:
> Whether XDoclet or annotations - please everyone contemplating or
> implementing such things keep MVC in mind. There is a very good reason
> to have glue between a Java class and the HTML template and blurring
> these things together is a slippery slope into ugliness. Tapestry 3.0,
> though, does have leakage where the awkward abstract methods come into
> play and must match <property-specification>'s. In fact, I've been
> using get/setProperty() exclusively lately and not doing the 'abstract'
> thing.
>
> With page classes moving towards POJO's with Tapestry and HiveMind
> having the smarts to wire things together, XDoclet usage would be
> pointless. Maybe the same would be the case with annotations too.
>
> Howard - what kinds of annotations are you thinking make sense in Java
> classes?
>
> Erik
>
>
> On Feb 10, 2005, at 3:29 PM, Howard Lewis Ship wrote:
>
> > I'm also looking forward to creating a Tapestry add-on based on JDK
> > 1.5 that would use annotations to substitute for all, or some of, the
> > XML page specification.
> >
> >
> > On Thu, 10 Feb 2005 15:14:13 -0500, Erik Hatcher
> > <er...@ehatchersolutions.com> wrote:
> >> When I first came to Tapestry, I was doing Struts and EJB development
> >> where we had a lot of XDoclet going on - in fact I built the
> >> <strutsvalidationxml> subtask in XDoclet because of the duplication we
> >> were encountering.
> >>
> >> At first I thought using XDoclet to do exactly what you've done made a
> >> lot of sense. After using Tapestry for a while I realized that there
> >> is a pretty clean separation of concerns and that XDoclet would only
> >> make a mess of things. To do XDoclet templating/subtasks very nicely
> >> you have to really think through things a lot. For example - what if
> >> I
> >> want an abstract property specification getter... the XDoclet
> >> infrastructure should recognize that either automatically or by an
> >> @tag
> >> on the getter to generate the <property-specification> element.
> >> Otherwise, if you specify the whole .page information in the class
> >> header javadoc you will inevitably be duplicating yourself somewhere.
> >> I view XDoclet as a nice solution to some ugly problems, and don't
> >> feel
> >> Tapestry suffers from those ugly DRY (don't repeat yourself)
> >> violations
> >> out there.
> >>
> >> I do applaud Michael for doing this - it'll help "sell" Tapestry to
> >> shops that are entrenched in the XDoclet mindset.
> >>
> >> Erik
> >>
> >>
> >> On Feb 10, 2005, at 2:31 PM, Newcomb, Michael P. wrote:
> >>
> >>> I just wanted to let the Tapestry users know that I have added
> >>> Tapestry tag
> >>> support to XDoclet (xdoclet.sourceforge.net). You can now do things
> >>> like:
> >>>
> >>> /**
> >>> * @tapestry.page-specification description="a description"
> >>> *
> >>> * @tapestry.property name="displayName" value="My Cool Page"
> >>> *
> >>> * @tapestry.component id="e" type="Foreach"
> >>> * @tapestry.binding component="e" name="value" expression="names"
> >>> *
> >>> * @tapestry.component id="link" type="PageLink"
> >>> * @tapestry.binding component="link" name="page" expression="name"
> >>> * @tapestry.binding component="link" name="disabled"
> >>> * expression="disabledPageLink"
> >>> */
> >>> public class MyPage
> >>> extends BasePage
> >>> {
> >>> ...
> >>> }
> >>>
> >>> and it will auto-generate your MyPage.page file.
> >>>
> >>> Anyway, I have found it useful to manage my .page/jwc file from
> >>> inside
> >>> my
> >>> .java file.
> >>>
> >>> Thanks,
> >>> Michael
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
> ---------------------------------------------------------------------
> 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
property keyword
Posted by Konstantin Ignatyev <kg...@yahoo.com>.
I think that C# implementation of the feature is plain
UGLY! I was really amazed why the same guy who did
ObjectPascal(Delphi) allowed such ugly syntax.
--- Kevin Menard <ni...@negativetwenty.net> wrote:
>
> On Feb 11, 2005, at 10:20 AM, Jamie Orchard-Hays
> wrote:
>
> > Yeah, Ruby has something like this as well. You
> declare a property
> > with whatever access you want to it--not this
> get/set crap. That would
> > have been a nice feature to put in Java 5. Ach.
>
> Getting even closer to Java, C# has this feature. I
> don't know if this
> has something to do with it. Right now, most people
> think C# is a Java
> clone, not vice versa.
>
> --
> Kevin
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
>
=====
Konstantin Ignatyev
PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2,700 tons of CFCs to the stratosphere, and increase their population by 263,000
Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools. New York: State University of New York Press, 1997: (4) (5) (p.206)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Best Practices: was "XDoclet " [auf Viren geprueft]
Posted by Kevin Menard <ni...@negativetwenty.net>.
On Feb 11, 2005, at 10:20 AM, Jamie Orchard-Hays wrote:
> Yeah, Ruby has something like this as well. You declare a property
> with whatever access you want to it--not this get/set crap. That would
> have been a nice feature to put in Java 5. Ach.
Getting even closer to Java, C# has this feature. I don't know if this
has something to do with it. Right now, most people think C# is a Java
clone, not vice versa.
--
Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Best Practices: was "XDoclet " [auf Viren geprueft]
Posted by Jamie Orchard-Hays <ja...@dang.com>.
Yeah, Ruby has something like this as well. You declare a property with
whatever access you want to it--not this get/set crap. That would have been
a nice feature to put in Java 5. Ach.
----- Original Message -----
From: "Konstantin Iignatyev" <kg...@yahoo.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Friday, February 11, 2005 9:53 AM
Subject: Re: Best Practices: was "XDoclet " [auf Viren geprueft]
> Just a rant:
>
> Why the hell Java does not have "property" keyword with ObjectPaskal
> syntax?!?!
>
> property myField; [read readMyPropertyMethod;] [write mySetterMethod;]
>
> That would solve this abstraction problem and resolve all that get/set
> mess and ambiguity....
>
> Maybe we should lobby Sun somehow?
>
>
>
> PLEASE keep page fields strongly typed,
>
>
> Howard Lewis Ship wrote:
>
>>So, if we move properties (including parameters) into the component,
>>we can get rid of a lot of enhancement. But we have to use untyped
>>collections (Maps), and we seperate the logic (in listener methods)
>>from the data (in the component). And we still haven't figured out
>>how the peer learns of the component (which would be injection).
>>
>>For my mind, if even one property has to be abstract, then there's no
>>additional dissadvantage to them all being abstract, and keeping
>>more-or-less the status quo (with respect to abstract classes .... but
>>I'm very committed to removing the necessity of extending Tapestry
>>classes).
>>
>>Please take these thoughts for what they are ... off the top of my head.
>>
>>
>
> --
> Thanks,
>
> Konstantin Ignatyev
>
> http://www.kgionline.com
>
>
>
>
>
> PS: If this is a typical day on planet earth, humans will add fifteen
> million tons of carbon to the atmosphere, destroy 115 square miles of
> tropical rainforest, create seventy-two miles of desert, eliminate between
> forty to one hundred species, erode seventy-one million tons of topsoil,
> add 2.700 tons of CFCs to the stratosphere, and increase their population
> by 263.000
>
> Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs
> a Strategy for Reforming Universities and Public Schools. New York:
> State University of New York Press, 1997: (4) (5) (p.206)
>
>
> ---------------------------------------------------------------------
> 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: Best Practices: was "XDoclet " [auf Viren geprueft]
Posted by Konstantin Iignatyev <kg...@yahoo.com>.
Just a rant:
Why the hell Java does not have "property" keyword with ObjectPaskal
syntax?!?!
property myField; [read readMyPropertyMethod;] [write mySetterMethod;]
That would solve this abstraction problem and resolve all that get/set
mess and ambiguity....
Maybe we should lobby Sun somehow?
PLEASE keep page fields strongly typed,
Howard Lewis Ship wrote:
>So, if we move properties (including parameters) into the component,
>we can get rid of a lot of enhancement. But we have to use untyped
>collections (Maps), and we seperate the logic (in listener methods)
>from the data (in the component). And we still haven't figured out
>how the peer learns of the component (which would be injection).
>
>For my mind, if even one property has to be abstract, then there's no
>additional dissadvantage to them all being abstract, and keeping
>more-or-less the status quo (with respect to abstract classes .... but
>I'm very committed to removing the necessity of extending Tapestry
>classes).
>
>Please take these thoughts for what they are ... off the top of my head.
>
>
>
--
Thanks,
Konstantin Ignatyev
http://www.kgionline.com
PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2.700 tons of CFCs to the stratosphere, and increase their population by 263.000
Bowers, C.A. The Culture of Denial:
Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools.
New York: State University of New York Press, 1997: (4) (5) (p.206)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Best Practices: was "XDoclet " [auf Viren geprueft]
Posted by Howard Lewis Ship <hl...@gmail.com>.
I've been giving serious thought to how to get rid of the
"abstractness" of Tapestry, but the ideas really are not backwards
compatible to 3.x. It will be part of Tapestry 4.0, it it ever
happens.
First off, we'd need a 1-1 relationship between components (including
pages) and Java classes. This is necessary, because the loading of
each component will need to be intercepted at the class loader level,
and instance variables will need to be stripped out and replaced ...
the same kind of enhancements that occur today.
This does raise the issue that what you test is not quite what you run
... but that's true today, if you use the Creator on your abstract
classes.
This introduced some new problems ... such as the desire to have much
more dynamically generated pages and components. It's conceptually
possible to fabricate the specification in 3.x, but you'd have to
fabricate entire classes in 4.0.
.... or wecould go in an entirely different direction, where we
seperate back out the logic (in a POJO) from state. So instead of
seeing properties and parameters as JavaBeans properties, we see them
as untyped objects stored in a peer component.
Background: My vision for Tapestry 4.0 is that your pages and
components will be POJOs that will have. Most of the strunctural and
behavioral things we associate with components today would be the
responsibility of the component, whose implementaiton would be private
to Tapestry, exposed only through a (streamline) Component interface.
Your code would write the peer, which is the container for business
logic, listener methods, and so forth.
My current thinking is that the peer would be enhanced, to inject a
component property, plus anything else you direct to be injected (as
in 3.1 today). The peer would still be abstract, with abstract
accessors ... it just wouldn't need to extend from a Tapestry class,
or even implement a Tapestry interface.
So, if we move properties (including parameters) into the component,
we can get rid of a lot of enhancement. But we have to use untyped
collections (Maps), and we seperate the logic (in listener methods)
from the data (in the component). And we still haven't figured out
how the peer learns of the component (which would be injection).
For my mind, if even one property has to be abstract, then there's no
additional dissadvantage to them all being abstract, and keeping
more-or-less the status quo (with respect to abstract classes .... but
I'm very committed to removing the necessity of extending Tapestry
classes).
Please take these thoughts for what they are ... off the top of my head.
On Fri, 11 Feb 2005 08:39:38 -0500, Jamie Orchard-Hays <ja...@dang.com> wrote:
> If I remember correctly, Howard said that in 3.1 you would only need to
> declare a property in the page spec *or* an abstract getter/setter in
> the java file, but not both: DRY.
>
>
> On Feb 11, 2005, at 8:28 AM, Erik Hatcher wrote:
>
> >
> > There are no substantial advantages or disadvantages. It's more a
> > matter of taste. The 'abstract' thing bothers me... and I believe 3.1
> > will solve a lot of this by making it unnecessary to have them
> > (Howard??). Having true getters/setters for information going into or
> > out of a page is what I'd like to see, without having the state
> > management worries that we currently have in 3.0.
>
> ---------------------------------------------------------------------
> 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
Re: Best Practices: was "XDoclet " [auf Viren geprueft]
Posted by Jamie Orchard-Hays <ja...@dang.com>.
If I remember correctly, Howard said that in 3.1 you would only need to
declare a property in the page spec *or* an abstract getter/setter in
the java file, but not both: DRY.
On Feb 11, 2005, at 8:28 AM, Erik Hatcher wrote:
>
> There are no substantial advantages or disadvantages. It's more a
> matter of taste. The 'abstract' thing bothers me... and I believe 3.1
> will solve a lot of this by making it unnecessary to have them
> (Howard??). Having true getters/setters for information going into or
> out of a page is what I'd like to see, without having the state
> management worries that we currently have in 3.0.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Best Practices: was "XDoclet " [auf Viren geprueft]
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Feb 11, 2005, at 5:39 AM, Jonathan O'Connor wrote:
> Erik,
> You wrote:
> In fact, I've been
> using get/setProperty() exclusively lately and not doing the 'abstract'
> thing.
>
> But, you still have to supply the name of the property as a param for
> get/setProperty, and I, for one, think it is easier to have IDE support
> and strong typing.
No argument there. I still get strong typing by casting, of course.
By declaring types in the page specification, you're losing type
checking in the IDE and with OGNL expressions you have no IDE type
checking either. So being loose with types at some levels is something
we need to get used to.
> What happens when you mistype the property name? How quickly does the
> error show up? I suppose you get more NPEs at runtime.
I bet I get less NPE's at runtime than most :)
But sure, mistyping causes errors. What happens if you mistype the
class name in a page specification? Or mistype an OGNL expression?
> Can you give a list of advantages/disadvantages of your technique?
There are no substantial advantages or disadvantages. It's more a
matter of taste. The 'abstract' thing bothers me... and I believe 3.1
will solve a lot of this by making it unnecessary to have them
(Howard??). Having true getters/setters for information going into or
out of a page is what I'd like to see, without having the state
management worries that we currently have in 3.0.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Best Practices: was "XDoclet " [auf Viren geprueft]
Posted by Jonathan O'Connor <Jo...@xcom.de>.
Erik,
You wrote:
In fact, I've been
using get/setProperty() exclusively lately and not doing the 'abstract'
thing.
But, you still have to supply the name of the property as a param for
get/setProperty, and I, for one, think it is easier to have IDE support
and strong typing.
What happens when you mistype the property name? How quickly does the
error show up? I suppose you get more NPEs at runtime.
Can you give a list of advantages/disadvantages of your technique?
Ciao,
Jonathan O'Connor
XCOM Dublin
*** Aktuelle Veranstaltungen der XCOM AG ***
XCOM laedt ein zur IBM Workplace Roadshow in Frankfurt (16.02.2005), Duesseldorf (23.02.2005) und Berlin (02.03.2005)
Anmeldung und Information unter http://lotus.xcom.de/events
Workshop-Reihe "Mobilisierung von Lotus Notes Applikationen" in Frankfurt (17.02.2005), Duesseldorf (24.02.2005) und Berlin (05.03.2005)
Anmeldung und Information unter http://lotus.xcom.de/events
*** XCOM AG Legal Disclaimer ***
Diese E-Mail einschliesslich ihrer Anhaenge ist vertraulich und ist allein fur den Gebrauch durch den vorgesehenen Empfaenger bestimmt. Dritten ist das Lesen, Verteilen oder Weiterleiten dieser E-Mail untersagt. Wir bitten, eine fehlgeleitete E-Mail unverzueglich vollstaendig zu loeschen und uns eine Nachricht zukommen zu lassen.
This email may contain material that is confidential and for the sole use of the intended recipient. Any review, distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Re: XDoclet
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
Whether XDoclet or annotations - please everyone contemplating or
implementing such things keep MVC in mind. There is a very good reason
to have glue between a Java class and the HTML template and blurring
these things together is a slippery slope into ugliness. Tapestry 3.0,
though, does have leakage where the awkward abstract methods come into
play and must match <property-specification>'s. In fact, I've been
using get/setProperty() exclusively lately and not doing the 'abstract'
thing.
With page classes moving towards POJO's with Tapestry and HiveMind
having the smarts to wire things together, XDoclet usage would be
pointless. Maybe the same would be the case with annotations too.
Howard - what kinds of annotations are you thinking make sense in Java
classes?
Erik
On Feb 10, 2005, at 3:29 PM, Howard Lewis Ship wrote:
> I'm also looking forward to creating a Tapestry add-on based on JDK
> 1.5 that would use annotations to substitute for all, or some of, the
> XML page specification.
>
>
> On Thu, 10 Feb 2005 15:14:13 -0500, Erik Hatcher
> <er...@ehatchersolutions.com> wrote:
>> When I first came to Tapestry, I was doing Struts and EJB development
>> where we had a lot of XDoclet going on - in fact I built the
>> <strutsvalidationxml> subtask in XDoclet because of the duplication we
>> were encountering.
>>
>> At first I thought using XDoclet to do exactly what you've done made a
>> lot of sense. After using Tapestry for a while I realized that there
>> is a pretty clean separation of concerns and that XDoclet would only
>> make a mess of things. To do XDoclet templating/subtasks very nicely
>> you have to really think through things a lot. For example - what if
>> I
>> want an abstract property specification getter... the XDoclet
>> infrastructure should recognize that either automatically or by an
>> @tag
>> on the getter to generate the <property-specification> element.
>> Otherwise, if you specify the whole .page information in the class
>> header javadoc you will inevitably be duplicating yourself somewhere.
>> I view XDoclet as a nice solution to some ugly problems, and don't
>> feel
>> Tapestry suffers from those ugly DRY (don't repeat yourself)
>> violations
>> out there.
>>
>> I do applaud Michael for doing this - it'll help "sell" Tapestry to
>> shops that are entrenched in the XDoclet mindset.
>>
>> Erik
>>
>>
>> On Feb 10, 2005, at 2:31 PM, Newcomb, Michael P. wrote:
>>
>>> I just wanted to let the Tapestry users know that I have added
>>> Tapestry tag
>>> support to XDoclet (xdoclet.sourceforge.net). You can now do things
>>> like:
>>>
>>> /**
>>> * @tapestry.page-specification description="a description"
>>> *
>>> * @tapestry.property name="displayName" value="My Cool Page"
>>> *
>>> * @tapestry.component id="e" type="Foreach"
>>> * @tapestry.binding component="e" name="value" expression="names"
>>> *
>>> * @tapestry.component id="link" type="PageLink"
>>> * @tapestry.binding component="link" name="page" expression="name"
>>> * @tapestry.binding component="link" name="disabled"
>>> * expression="disabledPageLink"
>>> */
>>> public class MyPage
>>> extends BasePage
>>> {
>>> ...
>>> }
>>>
>>> and it will auto-generate your MyPage.page file.
>>>
>>> Anyway, I have found it useful to manage my .page/jwc file from
>>> inside
>>> my
>>> .java file.
>>>
>>> Thanks,
>>> Michael
>>>
>>
>> ---------------------------------------------------------------------
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: XDoclet
Posted by Massimo <ml...@gmail.com>.
On Fri, 11 Feb 2005 08:21:40 -0500, Erik Hatcher
<er...@ehatchersolutions.com> wrote:
> Again, I want to emphasize my objections to blurring the view with the
> behavior. Having components defined in @tags or annotations bothers
> me. Being able to switch a component in the specification without
> changing the Java code or the HTML template is one of Tapestry's
> strengths. Don't lose that separation.
I'm totally new to Tapestry, i mean didn't realize any app with this
framework, but when i first came accross it and start reading docs,
articles, threads and code i realize what Erik is talking about almost
immediatly and that is, by far, what makes me consider learning
tapestry.
Just want you to know what a non-user/new-user thinks about tapestry.
--
Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: XDoclet
Posted by Jamie Orchard-Hays <ja...@dang.com>.
I agree whole-heartedly.
Jamie
On Feb 11, 2005, at 8:21 AM, Erik Hatcher wrote:
>
> Again, I want to emphasize my objections to blurring the view with the
> behavior. Having components defined in @tags or annotations bothers
> me. Being able to switch a component in the specification without
> changing the Java code or the HTML template is one of Tapestry's
> strengths. Don't lose that separation.
>
> Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: XDoclet
Posted by Bryan Lewis <br...@maine.rr.com>.
Right on.
----- Original Message -----
From: "Erik Hatcher" <er...@ehatchersolutions.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Friday, February 11, 2005 8:21 AM
Subject: Re: XDoclet
> On Feb 11, 2005, at 5:23 AM, Marko Kocic wrote:
> > That would be great step forward to get rid of xml.
>
> Don't like XML?
>
> Again, I want to emphasize my objections to blurring the view with the
> behavior. Having components defined in @tags or annotations bothers
> me. Being able to switch a component in the specification without
> changing the Java code or the HTML template is one of Tapestry's
> strengths. Don't lose that separation.
>
> Erik
>
>
> >
> >
> > On Thu, 10 Feb 2005 15:29:50 -0500, Howard Lewis Ship
> > <hl...@gmail.com> wrote:
> >> I'm also looking forward to creating a Tapestry add-on based on JDK
> >> 1.5 that would use annotations to substitute for all, or some of, the
> >> XML page specification.
> >>
> >> On Thu, 10 Feb 2005 15:14:13 -0500, Erik Hatcher
> >> <er...@ehatchersolutions.com> wrote:
> >>> When I first came to Tapestry, I was doing Struts and EJB development
> >>> where we had a lot of XDoclet going on - in fact I built the
> >>> <strutsvalidationxml> subtask in XDoclet because of the duplication
> >>> we
> >>> were encountering.
> >>>
> >>> At first I thought using XDoclet to do exactly what you've done made
> >>> a
> >>> lot of sense. After using Tapestry for a while I realized that there
> >>> is a pretty clean separation of concerns and that XDoclet would only
> >>> make a mess of things. To do XDoclet templating/subtasks very nicely
> >>> you have to really think through things a lot. For example - what
> >>> if I
> >>> want an abstract property specification getter... the XDoclet
> >>> infrastructure should recognize that either automatically or by an
> >>> @tag
> >>> on the getter to generate the <property-specification> element.
> >>> Otherwise, if you specify the whole .page information in the class
> >>> header javadoc you will inevitably be duplicating yourself somewhere.
> >>> I view XDoclet as a nice solution to some ugly problems, and don't
> >>> feel
> >>> Tapestry suffers from those ugly DRY (don't repeat yourself)
> >>> violations
> >>> out there.
> >>>
> >>> I do applaud Michael for doing this - it'll help "sell" Tapestry to
> >>> shops that are entrenched in the XDoclet mindset.
> >>>
> >>> Erik
> >>>
> >>>
> >>> On Feb 10, 2005, at 2:31 PM, Newcomb, Michael P. wrote:
> >>>
> >>>> I just wanted to let the Tapestry users know that I have added
> >>>> Tapestry tag
> >>>> support to XDoclet (xdoclet.sourceforge.net). You can now do things
> >>>> like:
> >>>>
> >>>> /**
> >>>> * @tapestry.page-specification description="a description"
> >>>> *
> >>>> * @tapestry.property name="displayName" value="My Cool Page"
> >>>> *
> >>>> * @tapestry.component id="e" type="Foreach"
> >>>> * @tapestry.binding component="e" name="value" expression="names"
> >>>> *
> >>>> * @tapestry.component id="link" type="PageLink"
> >>>> * @tapestry.binding component="link" name="page" expression="name"
> >>>> * @tapestry.binding component="link" name="disabled"
> >>>> * expression="disabledPageLink"
> >>>> */
> >>>> public class MyPage
> >>>> extends BasePage
> >>>> {
> >>>> ...
> >>>> }
> >>>>
> >>>> and it will auto-generate your MyPage.page file.
> >>>>
> >>>> Anyway, I have found it useful to manage my .page/jwc file from
> >>>> inside
> >>>> my
> >>>> .java file.
> >>>>
> >>>> Thanks,
> >>>> Michael
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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
> >>
> >>
> >
> >
> > --
> > Marko Kocic
> >
> > ---------------------------------------------------------------------
> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: XDoclet
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Feb 11, 2005, at 5:23 AM, Marko Kocic wrote:
> That would be great step forward to get rid of xml.
Don't like XML?
Again, I want to emphasize my objections to blurring the view with the
behavior. Having components defined in @tags or annotations bothers
me. Being able to switch a component in the specification without
changing the Java code or the HTML template is one of Tapestry's
strengths. Don't lose that separation.
Erik
>
>
> On Thu, 10 Feb 2005 15:29:50 -0500, Howard Lewis Ship
> <hl...@gmail.com> wrote:
>> I'm also looking forward to creating a Tapestry add-on based on JDK
>> 1.5 that would use annotations to substitute for all, or some of, the
>> XML page specification.
>>
>> On Thu, 10 Feb 2005 15:14:13 -0500, Erik Hatcher
>> <er...@ehatchersolutions.com> wrote:
>>> When I first came to Tapestry, I was doing Struts and EJB development
>>> where we had a lot of XDoclet going on - in fact I built the
>>> <strutsvalidationxml> subtask in XDoclet because of the duplication
>>> we
>>> were encountering.
>>>
>>> At first I thought using XDoclet to do exactly what you've done made
>>> a
>>> lot of sense. After using Tapestry for a while I realized that there
>>> is a pretty clean separation of concerns and that XDoclet would only
>>> make a mess of things. To do XDoclet templating/subtasks very nicely
>>> you have to really think through things a lot. For example - what
>>> if I
>>> want an abstract property specification getter... the XDoclet
>>> infrastructure should recognize that either automatically or by an
>>> @tag
>>> on the getter to generate the <property-specification> element.
>>> Otherwise, if you specify the whole .page information in the class
>>> header javadoc you will inevitably be duplicating yourself somewhere.
>>> I view XDoclet as a nice solution to some ugly problems, and don't
>>> feel
>>> Tapestry suffers from those ugly DRY (don't repeat yourself)
>>> violations
>>> out there.
>>>
>>> I do applaud Michael for doing this - it'll help "sell" Tapestry to
>>> shops that are entrenched in the XDoclet mindset.
>>>
>>> Erik
>>>
>>>
>>> On Feb 10, 2005, at 2:31 PM, Newcomb, Michael P. wrote:
>>>
>>>> I just wanted to let the Tapestry users know that I have added
>>>> Tapestry tag
>>>> support to XDoclet (xdoclet.sourceforge.net). You can now do things
>>>> like:
>>>>
>>>> /**
>>>> * @tapestry.page-specification description="a description"
>>>> *
>>>> * @tapestry.property name="displayName" value="My Cool Page"
>>>> *
>>>> * @tapestry.component id="e" type="Foreach"
>>>> * @tapestry.binding component="e" name="value" expression="names"
>>>> *
>>>> * @tapestry.component id="link" type="PageLink"
>>>> * @tapestry.binding component="link" name="page" expression="name"
>>>> * @tapestry.binding component="link" name="disabled"
>>>> * expression="disabledPageLink"
>>>> */
>>>> public class MyPage
>>>> extends BasePage
>>>> {
>>>> ...
>>>> }
>>>>
>>>> and it will auto-generate your MyPage.page file.
>>>>
>>>> Anyway, I have found it useful to manage my .page/jwc file from
>>>> inside
>>>> my
>>>> .java file.
>>>>
>>>> Thanks,
>>>> Michael
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
>
> --
> Marko Kocic
>
> ---------------------------------------------------------------------
> 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: XDoclet
Posted by Marko Kocic <ma...@gmail.com>.
That would be great step forward to get rid of xml.
On Thu, 10 Feb 2005 15:29:50 -0500, Howard Lewis Ship <hl...@gmail.com> wrote:
> I'm also looking forward to creating a Tapestry add-on based on JDK
> 1.5 that would use annotations to substitute for all, or some of, the
> XML page specification.
>
> On Thu, 10 Feb 2005 15:14:13 -0500, Erik Hatcher
> <er...@ehatchersolutions.com> wrote:
> > When I first came to Tapestry, I was doing Struts and EJB development
> > where we had a lot of XDoclet going on - in fact I built the
> > <strutsvalidationxml> subtask in XDoclet because of the duplication we
> > were encountering.
> >
> > At first I thought using XDoclet to do exactly what you've done made a
> > lot of sense. After using Tapestry for a while I realized that there
> > is a pretty clean separation of concerns and that XDoclet would only
> > make a mess of things. To do XDoclet templating/subtasks very nicely
> > you have to really think through things a lot. For example - what if I
> > want an abstract property specification getter... the XDoclet
> > infrastructure should recognize that either automatically or by an @tag
> > on the getter to generate the <property-specification> element.
> > Otherwise, if you specify the whole .page information in the class
> > header javadoc you will inevitably be duplicating yourself somewhere.
> > I view XDoclet as a nice solution to some ugly problems, and don't feel
> > Tapestry suffers from those ugly DRY (don't repeat yourself) violations
> > out there.
> >
> > I do applaud Michael for doing this - it'll help "sell" Tapestry to
> > shops that are entrenched in the XDoclet mindset.
> >
> > Erik
> >
> >
> > On Feb 10, 2005, at 2:31 PM, Newcomb, Michael P. wrote:
> >
> > > I just wanted to let the Tapestry users know that I have added
> > > Tapestry tag
> > > support to XDoclet (xdoclet.sourceforge.net). You can now do things
> > > like:
> > >
> > > /**
> > > * @tapestry.page-specification description="a description"
> > > *
> > > * @tapestry.property name="displayName" value="My Cool Page"
> > > *
> > > * @tapestry.component id="e" type="Foreach"
> > > * @tapestry.binding component="e" name="value" expression="names"
> > > *
> > > * @tapestry.component id="link" type="PageLink"
> > > * @tapestry.binding component="link" name="page" expression="name"
> > > * @tapestry.binding component="link" name="disabled"
> > > * expression="disabledPageLink"
> > > */
> > > public class MyPage
> > > extends BasePage
> > > {
> > > ...
> > > }
> > >
> > > and it will auto-generate your MyPage.page file.
> > >
> > > Anyway, I have found it useful to manage my .page/jwc file from inside
> > > my
> > > .java file.
> > >
> > > Thanks,
> > > Michael
> > >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
Marko Kocic
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: XDoclet
Posted by Howard Lewis Ship <hl...@gmail.com>.
I'm also looking forward to creating a Tapestry add-on based on JDK
1.5 that would use annotations to substitute for all, or some of, the
XML page specification.
On Thu, 10 Feb 2005 15:14:13 -0500, Erik Hatcher
<er...@ehatchersolutions.com> wrote:
> When I first came to Tapestry, I was doing Struts and EJB development
> where we had a lot of XDoclet going on - in fact I built the
> <strutsvalidationxml> subtask in XDoclet because of the duplication we
> were encountering.
>
> At first I thought using XDoclet to do exactly what you've done made a
> lot of sense. After using Tapestry for a while I realized that there
> is a pretty clean separation of concerns and that XDoclet would only
> make a mess of things. To do XDoclet templating/subtasks very nicely
> you have to really think through things a lot. For example - what if I
> want an abstract property specification getter... the XDoclet
> infrastructure should recognize that either automatically or by an @tag
> on the getter to generate the <property-specification> element.
> Otherwise, if you specify the whole .page information in the class
> header javadoc you will inevitably be duplicating yourself somewhere.
> I view XDoclet as a nice solution to some ugly problems, and don't feel
> Tapestry suffers from those ugly DRY (don't repeat yourself) violations
> out there.
>
> I do applaud Michael for doing this - it'll help "sell" Tapestry to
> shops that are entrenched in the XDoclet mindset.
>
> Erik
>
>
> On Feb 10, 2005, at 2:31 PM, Newcomb, Michael P. wrote:
>
> > I just wanted to let the Tapestry users know that I have added
> > Tapestry tag
> > support to XDoclet (xdoclet.sourceforge.net). You can now do things
> > like:
> >
> > /**
> > * @tapestry.page-specification description="a description"
> > *
> > * @tapestry.property name="displayName" value="My Cool Page"
> > *
> > * @tapestry.component id="e" type="Foreach"
> > * @tapestry.binding component="e" name="value" expression="names"
> > *
> > * @tapestry.component id="link" type="PageLink"
> > * @tapestry.binding component="link" name="page" expression="name"
> > * @tapestry.binding component="link" name="disabled"
> > * expression="disabledPageLink"
> > */
> > public class MyPage
> > extends BasePage
> > {
> > ...
> > }
> >
> > and it will auto-generate your MyPage.page file.
> >
> > Anyway, I have found it useful to manage my .page/jwc file from inside
> > my
> > .java file.
> >
> > Thanks,
> > Michael
> >
>
> ---------------------------------------------------------------------
> 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
Re: XDoclet
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
When I first came to Tapestry, I was doing Struts and EJB development
where we had a lot of XDoclet going on - in fact I built the
<strutsvalidationxml> subtask in XDoclet because of the duplication we
were encountering.
At first I thought using XDoclet to do exactly what you've done made a
lot of sense. After using Tapestry for a while I realized that there
is a pretty clean separation of concerns and that XDoclet would only
make a mess of things. To do XDoclet templating/subtasks very nicely
you have to really think through things a lot. For example - what if I
want an abstract property specification getter... the XDoclet
infrastructure should recognize that either automatically or by an @tag
on the getter to generate the <property-specification> element.
Otherwise, if you specify the whole .page information in the class
header javadoc you will inevitably be duplicating yourself somewhere.
I view XDoclet as a nice solution to some ugly problems, and don't feel
Tapestry suffers from those ugly DRY (don't repeat yourself) violations
out there.
I do applaud Michael for doing this - it'll help "sell" Tapestry to
shops that are entrenched in the XDoclet mindset.
Erik
On Feb 10, 2005, at 2:31 PM, Newcomb, Michael P. wrote:
> I just wanted to let the Tapestry users know that I have added
> Tapestry tag
> support to XDoclet (xdoclet.sourceforge.net). You can now do things
> like:
>
> /**
> * @tapestry.page-specification description="a description"
> *
> * @tapestry.property name="displayName" value="My Cool Page"
> *
> * @tapestry.component id="e" type="Foreach"
> * @tapestry.binding component="e" name="value" expression="names"
> *
> * @tapestry.component id="link" type="PageLink"
> * @tapestry.binding component="link" name="page" expression="name"
> * @tapestry.binding component="link" name="disabled"
> * expression="disabledPageLink"
> */
> public class MyPage
> extends BasePage
> {
> ...
> }
>
> and it will auto-generate your MyPage.page file.
>
> Anyway, I have found it useful to manage my .page/jwc file from inside
> my
> .java file.
>
> Thanks,
> Michael
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: XDoclet
Posted by Katie Macpherson <ka...@gmail.com>.
Cool!
Newcomb, Michael P. wrote:
>I just wanted to let the Tapestry users know that I have added Tapestry tag
>support to XDoclet (xdoclet.sourceforge.net). You can now do things like:
>
>/**
> * @tapestry.page-specification description="a description"
> *
> * @tapestry.property name="displayName" value="My Cool Page"
> *
> * @tapestry.component id="e" type="Foreach"
> * @tapestry.binding component="e" name="value" expression="names"
> *
> * @tapestry.component id="link" type="PageLink"
> * @tapestry.binding component="link" name="page" expression="name"
> * @tapestry.binding component="link" name="disabled"
> * expression="disabledPageLink"
> */
>public class MyPage
> extends BasePage
>{
> ...
>}
>
>and it will auto-generate your MyPage.page file.
>
>Anyway, I have found it useful to manage my .page/jwc file from inside my
>.java file.
>
>Thanks,
>Michael
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org