You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Viktor Szathmary <ph...@imapmail.org> on 2003/02/22 20:31:49 UTC
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
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
>
Tool Support vs. Implicit Components
Posted by "Howard M. Lewis Ship" <hl...@attbi.com>.
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
>
Tool Support vs. Implicit Components
Posted by "Howard M. Lewis Ship" <hl...@attbi.com>.
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: Proposed syntax for string bindings
Posted by Viktor Szathmary <ph...@imapmail.org>.
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
Re: Proposed syntax for string bindings
Posted by Geoff Longman <gl...@intelligentworks.com>.
> Tapestry -- giving folks the choice. And screwing poor Goeff constantly.
> How is he ever going to get Spindle working with 2.4?
Free time is my only concern right now.
Geoff
RE: Proposed syntax for string bindings
Posted by "Howard M. Lewis Ship" <hl...@attbi.com>.
Kind of necessitated by OGNL expression, which can be complex. In general,
I prefer the attribute-laden DTD, rather than a Sun-style everything
-is-an-element DTD.
So, with <static-binding> you can specify short values with an attribute
instead of wrapped char data now.
And with <binding> you can specify long values with wrapped char data
instead of an attribute.
Tapestry -- giving folks the choice. And screwing poor Goeff constantly.
How is he ever going to get Spindle working with 2.4?
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/proposals/tapestry
> -----Original Message-----
> From: Richard Lewis-Shell [mailto:rlewisshell@mac.com]
> Sent: Sunday, February 23, 2003 4:14 PM
> To: Tapestry development
> Subject: Re: Proposed syntax for string bindings
>
>
> I think I would prefer the prefix syntax. Not that I have
> had a chance to play with anything beyond 2.2 yet - because
> of this I could well be missing something, but for static
> strings wouldn't '"static string goes here"' work - ala OGNL
> expression bindings in 2.2. I guess that's just suggesting
> replacing {{ with ". Perhaps if we use a prefix syntax then
> static strings can be the default - ie. no prefix, assume
> what follows is a static string. But I think the prefix
> syntax is the way to go here - keep it explicit, rather than cryptic.
>
> BTW, I love the idea of being able to put a binding
> expression in the body of the binding tag rather than solely
> as attribute. +1! This brings the binding syntax back
> closer to its original syntax - anyone else (other than
> Howard!) remember that? Ahh, the good ol' days!
>
> R
>
> ----- Original Message -----
> From: "Neil Clayton" <ne...@cloudnine.net.nz>
> To: "Tapestry development" <ta...@jakarta.apache.org>
> Sent: Sunday, February 23, 2003 11:41 AM
> Subject: Re: Proposed syntax for string bindings
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Greetings All!
>
> Here's my 1c.
>
> Personally I would prefer a prefix type syntax, as it makes
> it easier to understand in my opinion. I can understand the
> [[]] or {{}} syntax, but prefixes are more explicit - there
> is no argument, no assumption, and it's "kind of" self
> documenting, in that it gives a hint to those in the dark
> about what it might relate to.
>
> Regards,
> Neil Clayton
>
> On Saturday 22 Feb 2003 10:28 pm, Howard M. Lewis Ship wrote:
> > I think, it comes down to aesthetics.
> >
> > The "[[ ... ]]" syntax was a bit controversial, just seemed
> like the
> > best idea I could come up with. I suppose it could have been
> > "ognl:..." instead. It's not too late to change it (the
> code is still
> > alpha), but
> I've
> > grown to really like this syntax.
> >
> > I've been doing a lot of work using the [[ ... ]] syntax
> and I've not
> > only gotten used to it, but I really like it! It looks
> very natural.
> > My intuition is that this syntax will stand out better for HTML
> > developers
> who
> > will have to "work around" the instrumentation on real projects.
> >
> > Given the "[[ ... ]]" syntax, a variation thereof makes
> sense for the
> other
> > use, getting a localized string. I just kind of like "{{ ... }}".
> >
> > However, this prefix concept is intriguing. It does simplify some
> > things; for example, supporting jxpath expressions at some
> point. It
> > unifies the syntax somewhat for expression and localized
> keys. So I'm
> > on the bench at this time.
> >
> > It may address an issue brought up by the folks in the
> class I taught
> > at Accurent; the XML specifications didn't have the [[ ...
> ]] syntax;
> > this confused them initially.
> >
> > Let's see if the discussion among the other committers and
> power-developers
> > heads in any particular direction.
> >
> > ----- Original Message -----
> > From: "Christian Sell" <ch...@netcologne.de>
> > To: "Tapestry development" <ta...@jakarta.apache.org>
> > Sent: Saturday, February 22, 2003 3:07 PM
> > Subject: Re: Proposed syntax for string bindings
> >
> > > Howard M. Lewis Ship wrote:
> > > > 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
> > > > }}"/>
> > >
> > > that sounds good in principle. I personally dont like the double
> > > braces much - is there any rationale behind that (other than the
> > > double brackets)? Just to throw in an alternative: what about
> > > something like "{i18n::logo-title}"? Seems more explicit to me..
> > >
> > > > 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
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> tapestry-dev-help@jakarta.apache.org
>
> - --
> Regards,
> Neil Clayton
>
> (PS: If you see strange text you don't understand underneath
> my email, don't worry - it's just my PGP signature)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
>
> iD8DBQE+V/ykLXcfQF3yrNoRAqJ3AKCkdRFGRU9kJCWZ/2dBiEI/tG3PjwCgjIBl
> Aa1g4Zybkq9m7pO3TMmc+0c=
> =ZBcG
> -----END PGP SIGNATURE-----
>
>
> ---------------------------------------------------------------------
> 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: Proposed syntax for string bindings
Posted by Richard Lewis-Shell <rl...@mac.com>.
I think I would prefer the prefix syntax. Not that I have had a chance to
play with anything beyond 2.2 yet - because of this I could well be missing
something, but for static strings wouldn't '"static string goes here"'
work - ala OGNL expression bindings in 2.2. I guess that's just suggesting
replacing {{ with ". Perhaps if we use a prefix syntax then static strings
can be the default - ie. no prefix, assume what follows is a static string.
But I think the prefix syntax is the way to go here - keep it explicit,
rather than cryptic.
BTW, I love the idea of being able to put a binding expression in the body
of the binding tag rather than solely as attribute. +1! This brings the
binding syntax back closer to its original syntax - anyone else (other than
Howard!) remember that? Ahh, the good ol' days!
R
----- Original Message -----
From: "Neil Clayton" <ne...@cloudnine.net.nz>
To: "Tapestry development" <ta...@jakarta.apache.org>
Sent: Sunday, February 23, 2003 11:41 AM
Subject: Re: Proposed syntax for string bindings
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Greetings All!
Here's my 1c.
Personally I would prefer a prefix type syntax, as it makes it easier to
understand in my opinion. I can understand the [[]] or {{}} syntax, but
prefixes are more explicit - there is no argument, no assumption, and it's
"kind of" self documenting, in that it gives a hint to those in the dark
about what it might relate to.
Regards,
Neil Clayton
On Saturday 22 Feb 2003 10:28 pm, Howard M. Lewis Ship wrote:
> I think, it comes down to aesthetics.
>
> The "[[ ... ]]" syntax was a bit controversial, just seemed like the best
> idea I could come up with. I suppose it could have been "ognl:..."
> instead. It's not too late to change it (the code is still alpha), but
I've
> grown to really like this syntax.
>
> I've been doing a lot of work using the [[ ... ]] syntax and I've not only
> gotten used to it, but I really like it! It looks very natural. My
> intuition is that this syntax will stand out better for HTML developers
who
> will have to "work around" the instrumentation on real projects.
>
> Given the "[[ ... ]]" syntax, a variation thereof makes sense for the
other
> use, getting a localized string. I just kind of like "{{ ... }}".
>
> However, this prefix concept is intriguing. It does simplify some things;
> for example, supporting jxpath expressions at some point. It unifies the
> syntax somewhat for expression and localized keys. So I'm on the bench at
> this time.
>
> It may address an issue brought up by the folks in the class I taught at
> Accurent; the XML specifications didn't have the [[ ... ]] syntax; this
> confused them initially.
>
> Let's see if the discussion among the other committers and
power-developers
> heads in any particular direction.
>
> ----- Original Message -----
> From: "Christian Sell" <ch...@netcologne.de>
> To: "Tapestry development" <ta...@jakarta.apache.org>
> Sent: Saturday, February 22, 2003 3:07 PM
> Subject: Re: Proposed syntax for string bindings
>
> > Howard M. Lewis Ship wrote:
> > > 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 }}"/>
> >
> > that sounds good in principle. I personally dont like the double braces
> > much - is there any rationale behind that (other than the double
> > brackets)? Just to throw in an alternative: what about something like
> > "{i18n::logo-title}"? Seems more explicit to me..
> >
> > > 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
- --
Regards,
Neil Clayton
(PS: If you see strange text you don't understand underneath my email, don't
worry - it's just my PGP signature)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE+V/ykLXcfQF3yrNoRAqJ3AKCkdRFGRU9kJCWZ/2dBiEI/tG3PjwCgjIBl
Aa1g4Zybkq9m7pO3TMmc+0c=
=ZBcG
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Proposed syntax for string bindings
Posted by Neil Clayton <ne...@cloudnine.net.nz>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Greetings All!
Here's my 1c.
Personally I would prefer a prefix type syntax, as it makes it easier to
understand in my opinion. I can understand the [[]] or {{}} syntax, but
prefixes are more explicit - there is no argument, no assumption, and it's
"kind of" self documenting, in that it gives a hint to those in the dark
about what it might relate to.
Regards,
Neil Clayton
On Saturday 22 Feb 2003 10:28 pm, Howard M. Lewis Ship wrote:
> I think, it comes down to aesthetics.
>
> The "[[ ... ]]" syntax was a bit controversial, just seemed like the best
> idea I could come up with. I suppose it could have been "ognl:..."
> instead. It's not too late to change it (the code is still alpha), but I've
> grown to really like this syntax.
>
> I've been doing a lot of work using the [[ ... ]] syntax and I've not only
> gotten used to it, but I really like it! It looks very natural. My
> intuition is that this syntax will stand out better for HTML developers who
> will have to "work around" the instrumentation on real projects.
>
> Given the "[[ ... ]]" syntax, a variation thereof makes sense for the other
> use, getting a localized string. I just kind of like "{{ ... }}".
>
> However, this prefix concept is intriguing. It does simplify some things;
> for example, supporting jxpath expressions at some point. It unifies the
> syntax somewhat for expression and localized keys. So I'm on the bench at
> this time.
>
> It may address an issue brought up by the folks in the class I taught at
> Accurent; the XML specifications didn't have the [[ ... ]] syntax; this
> confused them initially.
>
> Let's see if the discussion among the other committers and power-developers
> heads in any particular direction.
>
> ----- Original Message -----
> From: "Christian Sell" <ch...@netcologne.de>
> To: "Tapestry development" <ta...@jakarta.apache.org>
> Sent: Saturday, February 22, 2003 3:07 PM
> Subject: Re: Proposed syntax for string bindings
>
> > Howard M. Lewis Ship wrote:
> > > 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 }}"/>
> >
> > that sounds good in principle. I personally dont like the double braces
> > much - is there any rationale behind that (other than the double
> > brackets)? Just to throw in an alternative: what about something like
> > "{i18n::logo-title}"? Seems more explicit to me..
> >
> > > 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
- --
Regards,
Neil Clayton
(PS: If you see strange text you don't understand underneath my email, don't
worry - it's just my PGP signature)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE+V/ykLXcfQF3yrNoRAqJ3AKCkdRFGRU9kJCWZ/2dBiEI/tG3PjwCgjIBl
Aa1g4Zybkq9m7pO3TMmc+0c=
=ZBcG
-----END PGP SIGNATURE-----
Re: Proposed syntax for string bindings
Posted by "Howard M. Lewis Ship" <hl...@attbi.com>.
I think, it comes down to aesthetics.
The "[[ ... ]]" syntax was a bit controversial, just seemed like the best
idea I could come up with. I suppose it could have been "ognl:..." instead.
It's not too late to change it (the code is still alpha), but I've grown to
really like this syntax.
I've been doing a lot of work using the [[ ... ]] syntax and I've not only
gotten used to it, but I really like it! It looks very natural. My
intuition is that this syntax will stand out better for HTML developers who
will have to "work around" the instrumentation on real projects.
Given the "[[ ... ]]" syntax, a variation thereof makes sense for the other
use, getting a localized string. I just kind of like "{{ ... }}".
However, this prefix concept is intriguing. It does simplify some things;
for example, supporting jxpath expressions at some point. It unifies the
syntax somewhat for expression and localized keys. So I'm on the bench at
this time.
It may address an issue brought up by the folks in the class I taught at
Accurent; the XML specifications didn't have the [[ ... ]] syntax; this
confused them initially.
Let's see if the discussion among the other committers and power-developers
heads in any particular direction.
----- Original Message -----
From: "Christian Sell" <ch...@netcologne.de>
To: "Tapestry development" <ta...@jakarta.apache.org>
Sent: Saturday, February 22, 2003 3:07 PM
Subject: Re: Proposed syntax for string bindings
> Howard M. Lewis Ship wrote:
> > 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 }}"/>
> >
>
> that sounds good in principle. I personally dont like the double braces
> much - is there any rationale behind that (other than the double
> brackets)? Just to throw in an alternative: what about something like
> "{i18n::logo-title}"? Seems more explicit to me..
>
>
>
> > 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
> >>
Re: Proposed syntax for string bindings
Posted by Christian Sell <ch...@netcologne.de>.
Howard M. Lewis Ship wrote:
> 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 }}"/>
>
that sounds good in principle. I personally dont like the double braces
much - is there any rationale behind that (other than the double
brackets)? Just to throw in an alternative: what about something like
"{i18n::logo-title}"? Seems more explicit to me..
> 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
>
>
Proposed syntax for string bindings
Posted by "Howard M. Lewis Ship" <hl...@attbi.com>.
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
>