You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by "Howard M. Lewis Ship" <hl...@attbi.com> on 2003/02/23 00:51:18 UTC
Tool Support vs. Implicit Components
I spent several years saying that the complexity issue was about tools.
Spindle is great and Eclipse is great. And yet many folks use JBuilder,
NetBeans, IDEA, CodeGuide, Together/J, EMACS, ...
Nobody supports this kind of thing across more than one or two IDEs, always
leaving people out. Creating a stand alone editor would please even fewer
people than having just the single plugin for Eclipse.
Making Tapestry closer to JSP is ugly, yes. The seperation of concerns gets
very blurred ... but not broken.
The implicit components approach makes it very, very easy for new developers
to pick up Tapestry. By the time we're done, it will be easier to pick up
and use Tapestry than JSP, PHP, ASP or any of the others.
Tapestry is giving developers choice. There is an upward path, where users
can start with implicit everything and, if disciplined, switch over to
traditional, declared components. Better tools will make this transition
easier, but I don't feel we can get by on tools alone.
In fact, Tapestry 2.0 through 2.3 shows rather stagnant adoption rates, even
as Spindle got better and better. I feel confident that 2.4 is a step in
the right direction.
However, Tapestry's future really relies on far, far more developers
adopting it. All the changes in 2.4 make adoption of Tapestry significantly
easier.
I'm already seeing this, creating examples for the book (as well as creating
JUnit tests). Things fly together quickly, but are still very clean.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/proposals/tapestry
> -----Original Message-----
> From: Viktor Szathmary [mailto:phraktle@imapmail.org]
> Sent: Saturday, February 22, 2003 4:25 PM
> To: Apache Tapestry Developers
> Subject: Re: Proposed syntax for string bindings
>
>
> hi,
>
> hopefully constructive criticism follows, please don't get agitated :)
>
> i'm personally not very keen on the whole implicit components
> concept - i think a better approach is to keep things simpler
> from the tool developer standpoint (eg. keeping the spec in
> one place certainly makes it easy), and provide better tools.
>
> separating concerns is important - so is ease of use, i
> agree. however, if usability seems to be worse because
> concerns (html template vs. component defs) are separated,
> the right solution is to make it easier to switch between
> managing the two concerns, and not necessarily mixing them
> together. this is where JSP goes wrong, and this was one of
> Tapestry's advantages so far.
>
> imho, no matter how far you're tweaking implicit components,
> it will be ugly, and though to use for a novice without tool
> support anyway (has to jump to the reference all the time, to
> see params) - you'll also get this wacky [[ ]] stuff in the
> page (which of course will stay there forever, since nobody
> will sit down to factor it out, once the application reaches
> that level of complexity that it would be nice to separate it :)
>
> to sum it up, i think it would have been much better overall
> for tapestry usability, if all this dev. effort went into
> spindle instead of implicit components :)
>
> best regards,
> viktor
>
>
> On Sat, 22 Feb 2003 14:58:51 -0500, "Howard M. Lewis Ship"
> <hl...@attbi.com> said:
> > I'd prefer to defer this until people start using 2.4. Let
> folks get
> > used to 2.4 (with implicit and anonymous components) and
> see if that
> > addresses everyone's issues.
> >
> > I'm also wondering whether we should have a second
> expression syntax.
> >
> > <img jwcid="@Image" image="[[ assets.logo ]]" alt="{{
> logo-title }}"/>
> >
> > The double braces (instead of double brackets) could be used as the
> > localized string name, i.e., the equivalent of a
> <string-binding> in
> > the specification. Currently, in 2.4, to accomplish this requires
> > either using a declared component (in the specification,
> where you can
> > use <string-binding>), or something awkward like:
> >
> > <img jwcid="@Image" image="[[ assets.logo ]]" alt='
> > getString("logo-title")
> > '/>
> >
> > --
> > Howard M. Lewis Ship
> > Creator, Tapestry: Java Web Components
> > http://jakarta.apache.org/proposals/tapestry
> >
> >
> >
> > > -----Original Message-----
> > > From: Viktor Szathmary [mailto:phraktle@imapmail.org]
> > > Sent: Saturday, February 22, 2003 2:32 PM
> > > To: Apache Tapestry Developers
> > > Subject: RE: [Tapestry-developer] Image used more than once
> > >
> > >
> > > hi,
> > >
> > > On Fri, 21 Feb 2003 16:03:10 -0500, "Howard M. Lewis Ship"
> > > <hl...@attbi.com> said:
> > > >
> > > > Components *must* have unique ids.
> > > >
> > > > In the specification, you can use copy-of to make one
> > > component a copy
> > > > of another (copying its type and parameters).
> > > >
> > > > Removing tedious aspect of Tapestry such as this is a focus of
> > > > 2.4.
> > >
> > > would it be possible to implement something, where tapestry
> > > automatically creates the "copy-of" at template-parsing time?
> > > eg. if insertFoo is duplicated, it just creates an
> > > insertFooCopy1, insertFooCopy2, etc... or perhaps just a
> > > shorter notation, eg. <foo jwcid="copyOf@nsertFoo"> or sumtin?
> > >
> > > viktor
> > >
> > > --
> > > http://www.fastmail.fm - The way an email service should be
> > >
> > >
> --------------------------------------------------------------------
> > > -
> > > To unsubscribe, e-mail:
> tapestry-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> tapestry-dev-help@jakarta.apache.org
> > >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> tapestry-dev-help@jakarta.apache.org
> >
> >
>
> --
> http://www.fastmail.fm - Consolidate POP email and Hotmail in
> one place
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
Re: Tool Support vs. Implicit Components
Posted by "F.R. Da Costa Gomez" <dc...@fixed.com>.
Hi,
I have read your article with great interest but when I wanted to start
at the beginning I couldn't find the html file.
Any chance that you can send that another time?
Thx,
Fermin Da Costa Gomez
Peter Levart wrote:
>On nedelja 23 februar 2003 07:16 pop., Howard M. Lewis Ship wrote:
>
>
>>I really like giving the users a choice, and a path. Some folks will
>>always find a way to fight the framework I guess, rather than find the path
>>of least resistance. I'm hoping the book will help get people started down
>>the right track.
>>
>>
>>
>>>-----Original Message-----
>>>From: Geoff Longman [mailto:glongman@intelligentworks.com]
>>>Sent: Sunday, February 23, 2003 1:01 PM
>>>To: Tapestry development
>>>Cc: Tapestry Users
>>>Subject: Re: Tool Support vs. Implicit Components
>>>
>>>
>>>I tend to agree with Howard on the tools debate. Spindle is a
>>>good tool that I hope makes it easier to do stuff with
>>>Tapestry. But, as Howard has pointed out, not every one uses
>>>one tool and it's impossible to impose eclipse on the world.
>>>
>>>
>>>
>
>I'm one of those that don't use Eclipse. I thought: what about a
>non-interactive tool that could be used as a command-line tool or an Ant
>task? So I created one. It is not yet a product (I spent a weekend to create
>it), but I'm using it for my latest project successfully. It borrows the idea
>from XDoclet but starts the other way around - not with a Java source but
>with a HTML template. Let me illustrate what I'm talking about:
>
>1. The idea is to start with a HTML template that specifies component ids
>(jwcid) and their types. Since TapestryLite is not ready yet I choose a
>different syntax to specify component types than TapestryLite will use. I
>used the fact that you can specify any tag name for tapestry components, so I
>used the name of the tag to hold the component type. See attached file
>"DateScheduleEditor.html" for an example of such a HTML template.
>
>
Re: The missing DateScheduleEditor.html (Tool Support vs. Implicit
Components)
Posted by "F.R. Da Costa Gomez" <dc...@fixed.com>.
Hi Peter,
Found a print of your reply in this thread re. the non-eclipse command
line tool to work from the .html file towards abstract classes.
It read quite well so I was wondering whether you made a script, batch
file, ant-task or something else to accomplish this and whether it is in
such a state that others can test-drive it?
Might be convenient for a beginner like myself.
If so that would be great if not I will just plough on.
Thx,
Fermin DCG
Peter Levart wrote:
>It seems that the mailing list cuts out HTML attachments. For all those who
>are missing a DateScheduleEditor.html attachment in my previous posting, here
>it is again (packed in a zip)...
>
>Peter
>
>On torek 25 februar 2003 11:14 dop., Peter Levart wrote:
>
>
>>I'm one of those that don't use Eclipse. I thought: what about a
>>non-interactive tool that could be used as a command-line tool or an Ant
>>task? So I created one...
>>
>>
>>------------------------------------------------------------------------
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>
Re: The missing DateScheduleEditor.html (Tool Support vs. Implicit Components)
Posted by Peter Levart <Pe...@select-tech.si>.
It seems that the mailing list cuts out HTML attachments. For all those who
are missing a DateScheduleEditor.html attachment in my previous posting, here
it is again (packed in a zip)...
Peter
On torek 25 februar 2003 11:14 dop., Peter Levart wrote:
>
> I'm one of those that don't use Eclipse. I thought: what about a
> non-interactive tool that could be used as a command-line tool or an Ant
> task? So I created one...
Re: Tool Support vs. Implicit Components
Posted by Peter Levart <Pe...@select-tech.si>.
On nedelja 23 februar 2003 07:16 pop., Howard M. Lewis Ship wrote:
>
> I really like giving the users a choice, and a path. Some folks will
> always find a way to fight the framework I guess, rather than find the path
> of least resistance. I'm hoping the book will help get people started down
> the right track.
>
> > -----Original Message-----
> > From: Geoff Longman [mailto:glongman@intelligentworks.com]
> > Sent: Sunday, February 23, 2003 1:01 PM
> > To: Tapestry development
> > Cc: Tapestry Users
> > Subject: Re: Tool Support vs. Implicit Components
> >
> >
> > I tend to agree with Howard on the tools debate. Spindle is a
> > good tool that I hope makes it easier to do stuff with
> > Tapestry. But, as Howard has pointed out, not every one uses
> > one tool and it's impossible to impose eclipse on the world.
> >
I'm one of those that don't use Eclipse. I thought: what about a
non-interactive tool that could be used as a command-line tool or an Ant
task? So I created one. It is not yet a product (I spent a weekend to create
it), but I'm using it for my latest project successfully. It borrows the idea
from XDoclet but starts the other way around - not with a Java source but
with a HTML template. Let me illustrate what I'm talking about:
1. The idea is to start with a HTML template that specifies component ids
(jwcid) and their types. Since TapestryLite is not ready yet I choose a
different syntax to specify component types than TapestryLite will use. I
used the fact that you can specify any tag name for tapestry components, so I
used the name of the tag to hold the component type. See attached file
"DateScheduleEditor.html" for an example of such a HTML template.
2. The tool works in two stages: 1st it parses HTML template and
generates/updates the component specification file (.jwc). For this it
laverages the Tapestry API to obtain component specifications. The 2nd stage
is to use the specification file as input (after possibly manually editing
it) and to generate a Java source file of an abstract class that is used as a
superclass of a component class. The generated .jwc component specification
from the HTML template above is in the attached file
"DateScheduleEditor_generated.jwc". All the <component> tags are generated
with all the parameter bindings and documented (as specified in component
specifications).
3. Then comes the "thinking" part of what subcomponent bindings will be taken
from a transient property, what will be bound to persistent property, what
parameters (in case we're creating a component) will be used, etc. The
manually edited .jwc specification file then becomes something like
"DateScheduleEditor.jwc". Here I had to specify some additional "metadata"
for Java source generator and I choose to specify it in the XML comments that
are put into the content of the <binding> tags. I currently support the
following XML comments content (in the style of XDoclet tags):
@transient-property java-type="java.class.Name" access="r|rw"
@persistent-property java-type="java.class.Name" access="r|rw"
@abstract-property java-type="java.class.Name" access="r|rw"
The Java code generator understands simple property expressions in <binding>
tags (no property paths or ognl expressions) and generates property accessors
of particular type (as specified by XML comments inside the <property>
elements) together with private fields, firePropertyChange (for persistent
properties) and cleanup methods that set the private fields back to default
values from protected static fields that can be assigned in static
initialization blocks in subclass.
The Java code generator also understands expressions of the form
"listeners.methodName" and generates abstract listener methods.
It also generates property accessors with private fields for all
direction="in" parameters.
It could generate "IBinding <parameterName>Binding()" methods for other types
of parameters (like Tapestry 2.4 is already doing in runtime by generating a
subclass), etc.
4. The 2nd stage of the tool parses .jwc specification file and generates a
Java source of an abstract class that is used as a superclass of the
component class. The generated Java source file from the edited .jwc
specification file looks like "DateScheduleEditor_j2j.java".
When such an abstract class is specified as a superclass of a component class,
many IDEs (IDEA and NetBeans for example) allow you to implement all abstract
or unimplemented interface methods by inserting code in your source
automatically. The development cycle is now closed:
- a modification in the HTML template followed by a run of the "Html2Jwc" tool
updates the .jwc specification file with new subcomponents and their bindings
(all previously specified data is preserved).
- manually editing .jwc specification specifies additional data and "metadata"
about new subcomponents and their bindings.
- a run of the "Jwc2Java" tool re-generates the Java source of the component's
abstract superclass.
What do you think? If anyone is interested I could make an Ant task out of it
and submit it as a contribution to the Tapestry.
Peter
RE: Tool Support vs. Implicit Components
Posted by "Howard M. Lewis Ship" <hl...@attbi.com>.
That's true, but even if we threw out declared components entirely (-1 on
that!), Tapestry would be more than JSP can possibly be.
I really like giving the users a choice, and a path. Some folks will always
find a way to fight the framework I guess, rather than find the path of
least resistance. I'm hoping the book will help get people started down the
right track.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/proposals/tapestry
> -----Original Message-----
> From: Geoff Longman [mailto:glongman@intelligentworks.com]
> Sent: Sunday, February 23, 2003 1:01 PM
> To: Tapestry development
> Cc: Tapestry Users
> Subject: Re: Tool Support vs. Implicit Components
>
>
> I tend to agree with Howard on the tools debate. Spindle is a
> good tool that I hope makes it easier to do stuff with
> Tapestry. But, as Howard has pointed out, not every one uses
> one tool and it's impossible to impose eclipse on the world.
>
> There has been representation by some (JBOSS guy for one) that if one
> *needs* a tool like Spindle to create useful things with
> Tapestry, that is proof that Tapestry is too big to be useful.
>
> We know this is not true as its quite possible to build
> complex things without using any tool whatsoever.
>
> As for the implicit components thing, yes there is a danger
> that it might become too "JSP"ish, to the detriment of the framework.
>
> My opinion is that "just enough" be done to promote easy
> adoption. But, only "just enough". There is a danger that
> regardless of what we say or document that the implicit way
> will become "The Way" in the minds of new users. If this
> happens all you end up with is a JSP replacement. whoopie.
>
> My 2 cents.
>
> Geoff
>
>
>
> ----- Original Message -----
> From: "Howard M. Lewis Ship" <hl...@attbi.com>
> To: "'Tapestry development'" <ta...@jakarta.apache.org>
> Cc: "Tapestry Users" <ta...@jakarta.apache.org>
> Sent: Saturday, February 22, 2003 6:51 PM
> Subject: Tool Support vs. Implicit Components
>
>
> > I spent several years saying that the complexity issue was about
> > tools.
> >
> > Spindle is great and Eclipse is great. And yet many folks use
> > JBuilder, NetBeans, IDEA, CodeGuide, Together/J, EMACS, ...
> >
> > Nobody supports this kind of thing across more than one or two IDEs,
> always
> > leaving people out. Creating a stand alone editor would
> please even
> > fewer people than having just the single plugin for Eclipse.
> >
> > Making Tapestry closer to JSP is ugly, yes. The seperation of
> > concerns
> gets
> > very blurred ... but not broken.
> >
> > The implicit components approach makes it very, very easy for new
> developers
> > to pick up Tapestry. By the time we're done, it will be easier to
> > pick up and use Tapestry than JSP, PHP, ASP or any of the others.
> >
> > Tapestry is giving developers choice. There is an upward
> path, where
> users
> > can start with implicit everything and, if disciplined,
> switch over to
> > traditional, declared components. Better tools will make this
> > transition easier, but I don't feel we can get by on tools alone.
> >
> > In fact, Tapestry 2.0 through 2.3 shows rather stagnant adoption
> > rates,
> even
> > as Spindle got better and better. I feel confident that
> 2.4 is a step
> > in the right direction.
> >
> > However, Tapestry's future really relies on far, far more
> developers
> > adopting it. All the changes in 2.4 make adoption of Tapestry
> significantly
> > easier.
> >
> > I'm already seeing this, creating examples for the book (as well as
> creating
> > JUnit tests). Things fly together quickly, but are still
> very clean.
> >
> >
> > --
> > Howard M. Lewis Ship
> > Creator, Tapestry: Java Web Components
> > http://jakarta.apache.org/proposals/tapestry
> >
> >
> >
> > > -----Original Message-----
> > > From: Viktor Szathmary [mailto:phraktle@imapmail.org]
> > > Sent: Saturday, February 22, 2003 4:25 PM
> > > To: Apache Tapestry Developers
> > > Subject: Re: Proposed syntax for string bindings
> > >
> > >
> > > hi,
> > >
> > > hopefully constructive criticism follows, please don't
> get agitated
> > > :)
> > >
> > > i'm personally not very keen on the whole implicit components
> > > concept - i think a better approach is to keep things
> simpler from
> > > the tool developer standpoint (eg. keeping the spec in one place
> > > certainly makes it easy), and provide better tools.
> > >
> > > separating concerns is important - so is ease of use, i agree.
> > > however, if usability seems to be worse because concerns (html
> > > template vs. component defs) are separated, the right
> solution is to
> > > make it easier to switch between managing the two
> concerns, and not
> > > necessarily mixing them together. this is where JSP goes
> wrong, and
> > > this was one of Tapestry's advantages so far.
> > >
> > > imho, no matter how far you're tweaking implicit
> components, it will
> > > be ugly, and though to use for a novice without tool
> support anyway
> > > (has to jump to the reference all the time, to see
> params) - you'll
> > > also get this wacky [[ ]] stuff in the page (which of course will
> > > stay there forever, since nobody will sit down to factor it out,
> > > once the application reaches that level of complexity
> that it would
> > > be nice to separate it :)
> > >
> > > to sum it up, i think it would have been much better overall for
> > > tapestry usability, if all this dev. effort went into spindle
> > > instead of implicit components :)
> > >
> > > best regards,
> > > viktor
> > >
> > >
> > > On Sat, 22 Feb 2003 14:58:51 -0500, "Howard M. Lewis Ship"
> > > <hl...@attbi.com> said:
> > > > I'd prefer to defer this until people start using 2.4. Let
> > > folks get
> > > > used to 2.4 (with implicit and anonymous components) and
> > > see if that
> > > > addresses everyone's issues.
> > > >
> > > > I'm also wondering whether we should have a second
> > > expression syntax.
> > > >
> > > > <img jwcid="@Image" image="[[ assets.logo ]]" alt="{{
> > > logo-title }}"/>
> > > >
> > > > The double braces (instead of double brackets) could be used as
> > > > the localized string name, i.e., the equivalent of a
> > > <string-binding> in
> > > > the specification. Currently, in 2.4, to accomplish
> this requires
> > > > either using a declared component (in the specification,
> > > where you can
> > > > use <string-binding>), or something awkward like:
> > > >
> > > > <img jwcid="@Image" image="[[ assets.logo ]]" alt='
> > > > getString("logo-title")
> > > > '/>
> > > >
> > > > --
> > > > Howard M. Lewis Ship
> > > > Creator, Tapestry: Java Web Components
> > > > http://jakarta.apache.org/proposals/tapestry
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Viktor Szathmary [mailto:phraktle@imapmail.org]
> > > > > Sent: Saturday, February 22, 2003 2:32 PM
> > > > > To: Apache Tapestry Developers
> > > > > Subject: RE: [Tapestry-developer] Image used more than once
> > > > >
> > > > >
> > > > > hi,
> > > > >
> > > > > On Fri, 21 Feb 2003 16:03:10 -0500, "Howard M. Lewis Ship"
> > > > > <hl...@attbi.com> said:
> > > > > >
> > > > > > Components *must* have unique ids.
> > > > > >
> > > > > > In the specification, you can use copy-of to make one
> > > > > component a copy
> > > > > > of another (copying its type and parameters).
> > > > > >
> > > > > > Removing tedious aspect of Tapestry such as this is
> a focus of
> > > > > > 2.4.
> > > > >
> > > > > would it be possible to implement something, where tapestry
> > > > > automatically creates the "copy-of" at template-parsing time?
> > > > > eg. if insertFoo is duplicated, it just creates an
> > > > > insertFooCopy1, insertFooCopy2, etc... or perhaps just a
> > > > > shorter notation, eg. <foo jwcid="copyOf@nsertFoo"> or sumtin?
> > > > >
> > > > > viktor
> > > > >
> > > > > --
> > > > > http://www.fastmail.fm - The way an email service should be
> > > > >
> > > > >
> > >
> --------------------------------------------------------------------
> > > > > -
> > > > > To unsubscribe, e-mail:
> > > tapestry-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
> > > tapestry-dev-help@jakarta.apache.org
> > > > >
> > > >
> > > >
> > > >
> > >
> --------------------------------------------------------------------
> > > -
> > > > To unsubscribe, e-mail:
> > > > tapestry-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> > > tapestry-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > > --
> > > http://www.fastmail.fm - Consolidate POP email and Hotmail in one
> > > place
> > >
> > >
> --------------------------------------------------------------------
> > > -
> > > To unsubscribe, e-mail:
> tapestry-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> tapestry-dev-help@jakarta.apache.org
> > >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> tapestry-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
RE: Tool Support vs. Implicit Components
Posted by "Howard M. Lewis Ship" <hl...@attbi.com>.
That's true, but even if we threw out declared components entirely (-1 on
that!), Tapestry would be more than JSP can possibly be.
I really like giving the users a choice, and a path. Some folks will always
find a way to fight the framework I guess, rather than find the path of
least resistance. I'm hoping the book will help get people started down the
right track.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/proposals/tapestry
> -----Original Message-----
> From: Geoff Longman [mailto:glongman@intelligentworks.com]
> Sent: Sunday, February 23, 2003 1:01 PM
> To: Tapestry development
> Cc: Tapestry Users
> Subject: Re: Tool Support vs. Implicit Components
>
>
> I tend to agree with Howard on the tools debate. Spindle is a
> good tool that I hope makes it easier to do stuff with
> Tapestry. But, as Howard has pointed out, not every one uses
> one tool and it's impossible to impose eclipse on the world.
>
> There has been representation by some (JBOSS guy for one) that if one
> *needs* a tool like Spindle to create useful things with
> Tapestry, that is proof that Tapestry is too big to be useful.
>
> We know this is not true as its quite possible to build
> complex things without using any tool whatsoever.
>
> As for the implicit components thing, yes there is a danger
> that it might become too "JSP"ish, to the detriment of the framework.
>
> My opinion is that "just enough" be done to promote easy
> adoption. But, only "just enough". There is a danger that
> regardless of what we say or document that the implicit way
> will become "The Way" in the minds of new users. If this
> happens all you end up with is a JSP replacement. whoopie.
>
> My 2 cents.
>
> Geoff
>
>
>
> ----- Original Message -----
> From: "Howard M. Lewis Ship" <hl...@attbi.com>
> To: "'Tapestry development'" <ta...@jakarta.apache.org>
> Cc: "Tapestry Users" <ta...@jakarta.apache.org>
> Sent: Saturday, February 22, 2003 6:51 PM
> Subject: Tool Support vs. Implicit Components
>
>
> > I spent several years saying that the complexity issue was about
> > tools.
> >
> > Spindle is great and Eclipse is great. And yet many folks use
> > JBuilder, NetBeans, IDEA, CodeGuide, Together/J, EMACS, ...
> >
> > Nobody supports this kind of thing across more than one or two IDEs,
> always
> > leaving people out. Creating a stand alone editor would
> please even
> > fewer people than having just the single plugin for Eclipse.
> >
> > Making Tapestry closer to JSP is ugly, yes. The seperation of
> > concerns
> gets
> > very blurred ... but not broken.
> >
> > The implicit components approach makes it very, very easy for new
> developers
> > to pick up Tapestry. By the time we're done, it will be easier to
> > pick up and use Tapestry than JSP, PHP, ASP or any of the others.
> >
> > Tapestry is giving developers choice. There is an upward
> path, where
> users
> > can start with implicit everything and, if disciplined,
> switch over to
> > traditional, declared components. Better tools will make this
> > transition easier, but I don't feel we can get by on tools alone.
> >
> > In fact, Tapestry 2.0 through 2.3 shows rather stagnant adoption
> > rates,
> even
> > as Spindle got better and better. I feel confident that
> 2.4 is a step
> > in the right direction.
> >
> > However, Tapestry's future really relies on far, far more
> developers
> > adopting it. All the changes in 2.4 make adoption of Tapestry
> significantly
> > easier.
> >
> > I'm already seeing this, creating examples for the book (as well as
> creating
> > JUnit tests). Things fly together quickly, but are still
> very clean.
> >
> >
> > --
> > Howard M. Lewis Ship
> > Creator, Tapestry: Java Web Components
> > http://jakarta.apache.org/proposals/tapestry
> >
> >
> >
> > > -----Original Message-----
> > > From: Viktor Szathmary [mailto:phraktle@imapmail.org]
> > > Sent: Saturday, February 22, 2003 4:25 PM
> > > To: Apache Tapestry Developers
> > > Subject: Re: Proposed syntax for string bindings
> > >
> > >
> > > hi,
> > >
> > > hopefully constructive criticism follows, please don't
> get agitated
> > > :)
> > >
> > > i'm personally not very keen on the whole implicit components
> > > concept - i think a better approach is to keep things
> simpler from
> > > the tool developer standpoint (eg. keeping the spec in one place
> > > certainly makes it easy), and provide better tools.
> > >
> > > separating concerns is important - so is ease of use, i agree.
> > > however, if usability seems to be worse because concerns (html
> > > template vs. component defs) are separated, the right
> solution is to
> > > make it easier to switch between managing the two
> concerns, and not
> > > necessarily mixing them together. this is where JSP goes
> wrong, and
> > > this was one of Tapestry's advantages so far.
> > >
> > > imho, no matter how far you're tweaking implicit
> components, it will
> > > be ugly, and though to use for a novice without tool
> support anyway
> > > (has to jump to the reference all the time, to see
> params) - you'll
> > > also get this wacky [[ ]] stuff in the page (which of course will
> > > stay there forever, since nobody will sit down to factor it out,
> > > once the application reaches that level of complexity
> that it would
> > > be nice to separate it :)
> > >
> > > to sum it up, i think it would have been much better overall for
> > > tapestry usability, if all this dev. effort went into spindle
> > > instead of implicit components :)
> > >
> > > best regards,
> > > viktor
> > >
> > >
> > > On Sat, 22 Feb 2003 14:58:51 -0500, "Howard M. Lewis Ship"
> > > <hl...@attbi.com> said:
> > > > I'd prefer to defer this until people start using 2.4. Let
> > > folks get
> > > > used to 2.4 (with implicit and anonymous components) and
> > > see if that
> > > > addresses everyone's issues.
> > > >
> > > > I'm also wondering whether we should have a second
> > > expression syntax.
> > > >
> > > > <img jwcid="@Image" image="[[ assets.logo ]]" alt="{{
> > > logo-title }}"/>
> > > >
> > > > The double braces (instead of double brackets) could be used as
> > > > the localized string name, i.e., the equivalent of a
> > > <string-binding> in
> > > > the specification. Currently, in 2.4, to accomplish
> this requires
> > > > either using a declared component (in the specification,
> > > where you can
> > > > use <string-binding>), or something awkward like:
> > > >
> > > > <img jwcid="@Image" image="[[ assets.logo ]]" alt='
> > > > getString("logo-title")
> > > > '/>
> > > >
> > > > --
> > > > Howard M. Lewis Ship
> > > > Creator, Tapestry: Java Web Components
> > > > http://jakarta.apache.org/proposals/tapestry
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Viktor Szathmary [mailto:phraktle@imapmail.org]
> > > > > Sent: Saturday, February 22, 2003 2:32 PM
> > > > > To: Apache Tapestry Developers
> > > > > Subject: RE: [Tapestry-developer] Image used more than once
> > > > >
> > > > >
> > > > > hi,
> > > > >
> > > > > On Fri, 21 Feb 2003 16:03:10 -0500, "Howard M. Lewis Ship"
> > > > > <hl...@attbi.com> said:
> > > > > >
> > > > > > Components *must* have unique ids.
> > > > > >
> > > > > > In the specification, you can use copy-of to make one
> > > > > component a copy
> > > > > > of another (copying its type and parameters).
> > > > > >
> > > > > > Removing tedious aspect of Tapestry such as this is
> a focus of
> > > > > > 2.4.
> > > > >
> > > > > would it be possible to implement something, where tapestry
> > > > > automatically creates the "copy-of" at template-parsing time?
> > > > > eg. if insertFoo is duplicated, it just creates an
> > > > > insertFooCopy1, insertFooCopy2, etc... or perhaps just a
> > > > > shorter notation, eg. <foo jwcid="copyOf@nsertFoo"> or sumtin?
> > > > >
> > > > > viktor
> > > > >
> > > > > --
> > > > > http://www.fastmail.fm - The way an email service should be
> > > > >
> > > > >
> > >
> --------------------------------------------------------------------
> > > > > -
> > > > > To unsubscribe, e-mail:
> > > tapestry-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
> > > tapestry-dev-help@jakarta.apache.org
> > > > >
> > > >
> > > >
> > > >
> > >
> --------------------------------------------------------------------
> > > -
> > > > To unsubscribe, e-mail:
> > > > tapestry-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> > > tapestry-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > > --
> > > http://www.fastmail.fm - Consolidate POP email and Hotmail in one
> > > place
> > >
> > >
> --------------------------------------------------------------------
> > > -
> > > To unsubscribe, e-mail:
> tapestry-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> tapestry-dev-help@jakarta.apache.org
> > >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> tapestry-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
Re: Tool Support vs. Implicit Components
Posted by Geoff Longman <gl...@intelligentworks.com>.
I tend to agree with Howard on the tools debate. Spindle is a good tool that
I hope makes it easier to do stuff with Tapestry. But, as Howard has pointed
out, not every one uses one tool and it's impossible to impose eclipse on
the world.
There has been representation by some (JBOSS guy for one) that if one
*needs* a tool like Spindle to create useful things with Tapestry, that is
proof that Tapestry is too big to be useful.
We know this is not true as its quite possible to build complex things
without using any tool whatsoever.
As for the implicit components thing, yes there is a danger that it might
become too "JSP"ish, to the detriment of the framework.
My opinion is that "just enough" be done to promote easy adoption. But, only
"just enough". There is a danger that regardless of what we say or document
that the implicit way will become "The Way" in the minds of new users. If
this happens all you end up with is a JSP replacement. whoopie.
My 2 cents.
Geoff
----- Original Message -----
From: "Howard M. Lewis Ship" <hl...@attbi.com>
To: "'Tapestry development'" <ta...@jakarta.apache.org>
Cc: "Tapestry Users" <ta...@jakarta.apache.org>
Sent: Saturday, February 22, 2003 6:51 PM
Subject: Tool Support vs. Implicit Components
> I spent several years saying that the complexity issue was about tools.
>
> Spindle is great and Eclipse is great. And yet many folks use JBuilder,
> NetBeans, IDEA, CodeGuide, Together/J, EMACS, ...
>
> Nobody supports this kind of thing across more than one or two IDEs,
always
> leaving people out. Creating a stand alone editor would please even fewer
> people than having just the single plugin for Eclipse.
>
> Making Tapestry closer to JSP is ugly, yes. The seperation of concerns
gets
> very blurred ... but not broken.
>
> The implicit components approach makes it very, very easy for new
developers
> to pick up Tapestry. By the time we're done, it will be easier to pick up
> and use Tapestry than JSP, PHP, ASP or any of the others.
>
> Tapestry is giving developers choice. There is an upward path, where
users
> can start with implicit everything and, if disciplined, switch over to
> traditional, declared components. Better tools will make this transition
> easier, but I don't feel we can get by on tools alone.
>
> In fact, Tapestry 2.0 through 2.3 shows rather stagnant adoption rates,
even
> as Spindle got better and better. I feel confident that 2.4 is a step in
> the right direction.
>
> However, Tapestry's future really relies on far, far more developers
> adopting it. All the changes in 2.4 make adoption of Tapestry
significantly
> easier.
>
> I'm already seeing this, creating examples for the book (as well as
creating
> JUnit tests). Things fly together quickly, but are still very clean.
>
>
> --
> Howard M. Lewis Ship
> Creator, Tapestry: Java Web Components
> http://jakarta.apache.org/proposals/tapestry
>
>
>
> > -----Original Message-----
> > From: Viktor Szathmary [mailto:phraktle@imapmail.org]
> > Sent: Saturday, February 22, 2003 4:25 PM
> > To: Apache Tapestry Developers
> > Subject: Re: Proposed syntax for string bindings
> >
> >
> > hi,
> >
> > hopefully constructive criticism follows, please don't get agitated :)
> >
> > i'm personally not very keen on the whole implicit components
> > concept - i think a better approach is to keep things simpler
> > from the tool developer standpoint (eg. keeping the spec in
> > one place certainly makes it easy), and provide better tools.
> >
> > separating concerns is important - so is ease of use, i
> > agree. however, if usability seems to be worse because
> > concerns (html template vs. component defs) are separated,
> > the right solution is to make it easier to switch between
> > managing the two concerns, and not necessarily mixing them
> > together. this is where JSP goes wrong, and this was one of
> > Tapestry's advantages so far.
> >
> > imho, no matter how far you're tweaking implicit components,
> > it will be ugly, and though to use for a novice without tool
> > support anyway (has to jump to the reference all the time, to
> > see params) - you'll also get this wacky [[ ]] stuff in the
> > page (which of course will stay there forever, since nobody
> > will sit down to factor it out, once the application reaches
> > that level of complexity that it would be nice to separate it :)
> >
> > to sum it up, i think it would have been much better overall
> > for tapestry usability, if all this dev. effort went into
> > spindle instead of implicit components :)
> >
> > best regards,
> > viktor
> >
> >
> > On Sat, 22 Feb 2003 14:58:51 -0500, "Howard M. Lewis Ship"
> > <hl...@attbi.com> said:
> > > I'd prefer to defer this until people start using 2.4. Let
> > folks get
> > > used to 2.4 (with implicit and anonymous components) and
> > see if that
> > > addresses everyone's issues.
> > >
> > > I'm also wondering whether we should have a second
> > expression syntax.
> > >
> > > <img jwcid="@Image" image="[[ assets.logo ]]" alt="{{
> > logo-title }}"/>
> > >
> > > The double braces (instead of double brackets) could be used as the
> > > localized string name, i.e., the equivalent of a
> > <string-binding> in
> > > the specification. Currently, in 2.4, to accomplish this requires
> > > either using a declared component (in the specification,
> > where you can
> > > use <string-binding>), or something awkward like:
> > >
> > > <img jwcid="@Image" image="[[ assets.logo ]]" alt='
> > > getString("logo-title")
> > > '/>
> > >
> > > --
> > > Howard M. Lewis Ship
> > > Creator, Tapestry: Java Web Components
> > > http://jakarta.apache.org/proposals/tapestry
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Viktor Szathmary [mailto:phraktle@imapmail.org]
> > > > Sent: Saturday, February 22, 2003 2:32 PM
> > > > To: Apache Tapestry Developers
> > > > Subject: RE: [Tapestry-developer] Image used more than once
> > > >
> > > >
> > > > hi,
> > > >
> > > > On Fri, 21 Feb 2003 16:03:10 -0500, "Howard M. Lewis Ship"
> > > > <hl...@attbi.com> said:
> > > > >
> > > > > Components *must* have unique ids.
> > > > >
> > > > > In the specification, you can use copy-of to make one
> > > > component a copy
> > > > > of another (copying its type and parameters).
> > > > >
> > > > > Removing tedious aspect of Tapestry such as this is a focus of
> > > > > 2.4.
> > > >
> > > > would it be possible to implement something, where tapestry
> > > > automatically creates the "copy-of" at template-parsing time?
> > > > eg. if insertFoo is duplicated, it just creates an
> > > > insertFooCopy1, insertFooCopy2, etc... or perhaps just a
> > > > shorter notation, eg. <foo jwcid="copyOf@nsertFoo"> or sumtin?
> > > >
> > > > viktor
> > > >
> > > > --
> > > > http://www.fastmail.fm - The way an email service should be
> > > >
> > > >
> > --------------------------------------------------------------------
> > > > -
> > > > To unsubscribe, e-mail:
> > tapestry-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> > tapestry-dev-help@jakarta.apache.org
> > > >
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > tapestry-dev-help@jakarta.apache.org
> > >
> > >
> >
> > --
> > http://www.fastmail.fm - Consolidate POP email and Hotmail in
> > one place
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
Re: Tool Support vs. Implicit Components
Posted by Geoff Longman <gl...@intelligentworks.com>.
I tend to agree with Howard on the tools debate. Spindle is a good tool that
I hope makes it easier to do stuff with Tapestry. But, as Howard has pointed
out, not every one uses one tool and it's impossible to impose eclipse on
the world.
There has been representation by some (JBOSS guy for one) that if one
*needs* a tool like Spindle to create useful things with Tapestry, that is
proof that Tapestry is too big to be useful.
We know this is not true as its quite possible to build complex things
without using any tool whatsoever.
As for the implicit components thing, yes there is a danger that it might
become too "JSP"ish, to the detriment of the framework.
My opinion is that "just enough" be done to promote easy adoption. But, only
"just enough". There is a danger that regardless of what we say or document
that the implicit way will become "The Way" in the minds of new users. If
this happens all you end up with is a JSP replacement. whoopie.
My 2 cents.
Geoff
----- Original Message -----
From: "Howard M. Lewis Ship" <hl...@attbi.com>
To: "'Tapestry development'" <ta...@jakarta.apache.org>
Cc: "Tapestry Users" <ta...@jakarta.apache.org>
Sent: Saturday, February 22, 2003 6:51 PM
Subject: Tool Support vs. Implicit Components
> I spent several years saying that the complexity issue was about tools.
>
> Spindle is great and Eclipse is great. And yet many folks use JBuilder,
> NetBeans, IDEA, CodeGuide, Together/J, EMACS, ...
>
> Nobody supports this kind of thing across more than one or two IDEs,
always
> leaving people out. Creating a stand alone editor would please even fewer
> people than having just the single plugin for Eclipse.
>
> Making Tapestry closer to JSP is ugly, yes. The seperation of concerns
gets
> very blurred ... but not broken.
>
> The implicit components approach makes it very, very easy for new
developers
> to pick up Tapestry. By the time we're done, it will be easier to pick up
> and use Tapestry than JSP, PHP, ASP or any of the others.
>
> Tapestry is giving developers choice. There is an upward path, where
users
> can start with implicit everything and, if disciplined, switch over to
> traditional, declared components. Better tools will make this transition
> easier, but I don't feel we can get by on tools alone.
>
> In fact, Tapestry 2.0 through 2.3 shows rather stagnant adoption rates,
even
> as Spindle got better and better. I feel confident that 2.4 is a step in
> the right direction.
>
> However, Tapestry's future really relies on far, far more developers
> adopting it. All the changes in 2.4 make adoption of Tapestry
significantly
> easier.
>
> I'm already seeing this, creating examples for the book (as well as
creating
> JUnit tests). Things fly together quickly, but are still very clean.
>
>
> --
> Howard M. Lewis Ship
> Creator, Tapestry: Java Web Components
> http://jakarta.apache.org/proposals/tapestry
>
>
>
> > -----Original Message-----
> > From: Viktor Szathmary [mailto:phraktle@imapmail.org]
> > Sent: Saturday, February 22, 2003 4:25 PM
> > To: Apache Tapestry Developers
> > Subject: Re: Proposed syntax for string bindings
> >
> >
> > hi,
> >
> > hopefully constructive criticism follows, please don't get agitated :)
> >
> > i'm personally not very keen on the whole implicit components
> > concept - i think a better approach is to keep things simpler
> > from the tool developer standpoint (eg. keeping the spec in
> > one place certainly makes it easy), and provide better tools.
> >
> > separating concerns is important - so is ease of use, i
> > agree. however, if usability seems to be worse because
> > concerns (html template vs. component defs) are separated,
> > the right solution is to make it easier to switch between
> > managing the two concerns, and not necessarily mixing them
> > together. this is where JSP goes wrong, and this was one of
> > Tapestry's advantages so far.
> >
> > imho, no matter how far you're tweaking implicit components,
> > it will be ugly, and though to use for a novice without tool
> > support anyway (has to jump to the reference all the time, to
> > see params) - you'll also get this wacky [[ ]] stuff in the
> > page (which of course will stay there forever, since nobody
> > will sit down to factor it out, once the application reaches
> > that level of complexity that it would be nice to separate it :)
> >
> > to sum it up, i think it would have been much better overall
> > for tapestry usability, if all this dev. effort went into
> > spindle instead of implicit components :)
> >
> > best regards,
> > viktor
> >
> >
> > On Sat, 22 Feb 2003 14:58:51 -0500, "Howard M. Lewis Ship"
> > <hl...@attbi.com> said:
> > > I'd prefer to defer this until people start using 2.4. Let
> > folks get
> > > used to 2.4 (with implicit and anonymous components) and
> > see if that
> > > addresses everyone's issues.
> > >
> > > I'm also wondering whether we should have a second
> > expression syntax.
> > >
> > > <img jwcid="@Image" image="[[ assets.logo ]]" alt="{{
> > logo-title }}"/>
> > >
> > > The double braces (instead of double brackets) could be used as the
> > > localized string name, i.e., the equivalent of a
> > <string-binding> in
> > > the specification. Currently, in 2.4, to accomplish this requires
> > > either using a declared component (in the specification,
> > where you can
> > > use <string-binding>), or something awkward like:
> > >
> > > <img jwcid="@Image" image="[[ assets.logo ]]" alt='
> > > getString("logo-title")
> > > '/>
> > >
> > > --
> > > Howard M. Lewis Ship
> > > Creator, Tapestry: Java Web Components
> > > http://jakarta.apache.org/proposals/tapestry
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Viktor Szathmary [mailto:phraktle@imapmail.org]
> > > > Sent: Saturday, February 22, 2003 2:32 PM
> > > > To: Apache Tapestry Developers
> > > > Subject: RE: [Tapestry-developer] Image used more than once
> > > >
> > > >
> > > > hi,
> > > >
> > > > On Fri, 21 Feb 2003 16:03:10 -0500, "Howard M. Lewis Ship"
> > > > <hl...@attbi.com> said:
> > > > >
> > > > > Components *must* have unique ids.
> > > > >
> > > > > In the specification, you can use copy-of to make one
> > > > component a copy
> > > > > of another (copying its type and parameters).
> > > > >
> > > > > Removing tedious aspect of Tapestry such as this is a focus of
> > > > > 2.4.
> > > >
> > > > would it be possible to implement something, where tapestry
> > > > automatically creates the "copy-of" at template-parsing time?
> > > > eg. if insertFoo is duplicated, it just creates an
> > > > insertFooCopy1, insertFooCopy2, etc... or perhaps just a
> > > > shorter notation, eg. <foo jwcid="copyOf@nsertFoo"> or sumtin?
> > > >
> > > > viktor
> > > >
> > > > --
> > > > http://www.fastmail.fm - The way an email service should be
> > > >
> > > >
> > --------------------------------------------------------------------
> > > > -
> > > > To unsubscribe, e-mail:
> > tapestry-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> > tapestry-dev-help@jakarta.apache.org
> > > >
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > tapestry-dev-help@jakarta.apache.org
> > >
> > >
> >
> > --
> > http://www.fastmail.fm - Consolidate POP email and Hotmail in
> > one place
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>