You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Paul Cantrell <ca...@pobox.com> on 2005/12/13 02:14:39 UTC

Re: Further simplifying Tapestry (was: tapestry to JSF conversion)

> And wizards are helpful when you are not familiar with the  
> application of
> the tool, they are a friendly introduction to doing something.

Agreed, but ideally, the tool should be so elegant and self- 
explanatory that its natural interface is itself a friendly  
introduction. Obviously that's idealistic, but as ideals go, I think  
it's a good one.

My point is really that if you find yourself building a wizard, you  
should first ask yourself what in your design makes a wizard  
necessary, and see if can be simplified.

> don't keep me on the edge of my seat, but what does "your" Tap 5  
> not have
> that makes it better than Tap 4?

Umm... hmmm ... good question. Some ideas off the cuff:

I find myself writing too many throwaway get/set methods that are  
there only for the benefit of the template, and unused by any Java  
code. Perhaps some sort of implicit property mechanism could fix this.

The newly consolidated For component is an improvement, but still  
complex and confusing. One of the few things I miss about JSP is the  
standard taglib's iteration mechanisms.

Because of the way its link encoders work, Tapestry unnecessarily  
requires many separate servlet-mapping elements in web.xml in  
situations where a single mapping could cover many URL encodings. (I  
had an argument with HLS about this in Jira. Sorry, Howard.)

I'm sick of typing "ognl:".

There's perpetual confusion about passing parameters between pages.  
Perhaps the many types of link components could be consolidated into  
a single Link component, accompanied by a consolidation of the  
underlying services. I realize this is architecturally complicated,  
but from a user's point of view, it makes sense: I can link to any  
page (but this one by default), optionally invoking a listener,  
optionally passing it parameters. Why shouldn't that just be a single  
Link component? (The complexity of the answer to that question  
suggests that simplification is possible!)

So there's some ideas. They may be bad ideas, but I do think further  
aggressive simplification of this sort is a good thing. It's the sort  
of thing Tapestry is already doing; no reason to stop at 4.

Cheers,

Paul

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



---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org


RE: Further simplifying Tapestry (was: tapestry to JSF conversion)

Posted by Patrick Casey <pa...@adelphia.net>.
	Having written a wizard exactly like that for a very, very old
product, I'm with you, it's boring as hell :(. My customers loved it through
(at least the sysadmins did) because it saved them so much time.

	That's the concern I always have with open source projects like this
(and this isn't anything specific to you; I really *like* Spindle) i.e. the
final "polishing" phase of a product where the wizards get put in, the UI
gets tweaked, etc, rarely gets done because, frankly, it's boring grunt
work. 
	Anybody good enough to write the underlying functionality is bored
silly working on wizards or documentation or samples, or all that stuff :(.

	--- Pat

> -----Original Message-----
> From: Geoff Longman [mailto:glongman@gmail.com]
> Sent: Monday, December 12, 2005 8:15 PM
> To: Tapestry users
> Subject: Re: Further simplifying Tapestry (was: tapestry to JSF
> conversion)
> 
> To be honest, the wizards in Spindle are the part I like building the
> least. The builder is cool, the editors are neat, the wizards are
> drudgery.
> 
> Geoff
> 
> On 12/12/05, Patrick Casey <pa...@adelphia.net> wrote:
> >
> >        I'd love to see some sort of form generation wizard that was
> > integrated with either hibernate or just a simple POJO.
> >
> >        e.g.
> >
> >        "Build me a form to display an example of <package>.<class>"
> >
> >        And then have the wizard introspect the class, determine the
> fields
> > and types, and then create widgets as appropriate.
> >
> >        Nobody would use the result as an end product, but just getting
> the
> > fields on the form in an ugly vertical layout would get you about 40% of
> the
> > way there.
> >
> >        --- Pat
> >
> > > -----Original Message-----
> > > From: Geoff Longman [mailto:glongman@gmail.com]
> > > Sent: Monday, December 12, 2005 6:01 PM
> > > To: Tapestry users
> > > Subject: Re: Further simplifying Tapestry (was: tapestry to JSF
> > > conversion)
> > >
> > > On 12/12/05, Paul Cantrell <ca...@pobox.com> wrote:
> > > > > And wizards are helpful when you are not familiar with the
> > > > > application of
> > > > > the tool, they are a friendly introduction to doing something.
> > > >
> > > > Agreed, but ideally, the tool should be so elegant and self-
> > > > explanatory that its natural interface is itself a friendly
> > > > introduction. Obviously that's idealistic, but as ideals go, I think
> > > > it's a good one.
> > > >
> > > > My point is really that if you find yourself building a wizard, you
> > > > should first ask yourself what in your design makes a wizard
> > > > necessary, and see if can be simplified.
> > >
> > > Ok, I'll jump into this one with both feet using Tap3 and Spindle as
> an
> > > example.
> > >
> > > The new Component Wizard...oi
> > >
> > > In the default configuration you enter a name, have the option of
> > > choosing a project/namespace, indicate that a template should be
> > > generated (or not) .
> > >
> > > Pretty simple. The component is generated into the default location in
> > > the application - context/WEB-INF (for application, colocated with a
> > > library file if not) I believe off the top of my head.
> > >
> > > If one does not move to the second page, the component will be
> > > specificed to use the BaseComponent as a class. The second page is
> > > choose a class/create a class - not worth discussing.
> > >
> > > However the first page has grown into a morass of crud because there
> > > are so many different places one can put things. So much stuff that I
> > > had to add a Show/Hide advanced options button. Put it anywhere you
> > > want and the wizard will update the .application/.library file if
> > > necessary.
> > > Use a custom template to generate the spec/template if you like.
> > >
> > > It's messy and I've deliberately avoided adding more features as I'm
> > > of the belief the wizard was becoming LESS useful the more doodads
> > > were added.
> > >
> > > I'm a long way off from the Tap 4 redo of the wizards and frankly I
> > > think it's going to be worse (have no facts to back that up as of
> > > yet).
> > >
> > > I know I know blah blah. The point is the more you want it to do, the
> > > less useful it becomes (and more bug prone). And if you add everything
> > > the people ask for the tool itself becomes an impediment to learning
> > > the framework.
> > >
> > > Geoff
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
> 
> 
> --
> The Spindle guy.           http://spindle.sf.net
> Get help with Spindle:
> http://lists.sourceforge.net/mailman/listinfo/spindle-user
> Announcement Feed:
> http://www.jroller.com/rss/glongman?catname=/Announcements
> Feature Updates:            http://spindle.sf.net/updates
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org


Re: Further simplifying Tapestry (was: tapestry to JSF conversion)

Posted by Geoff Longman <gl...@gmail.com>.
To be honest, the wizards in Spindle are the part I like building the
least. The builder is cool, the editors are neat, the wizards are
drudgery.

Geoff

On 12/12/05, Patrick Casey <pa...@adelphia.net> wrote:
>
>        I'd love to see some sort of form generation wizard that was
> integrated with either hibernate or just a simple POJO.
>
>        e.g.
>
>        "Build me a form to display an example of <package>.<class>"
>
>        And then have the wizard introspect the class, determine the fields
> and types, and then create widgets as appropriate.
>
>        Nobody would use the result as an end product, but just getting the
> fields on the form in an ugly vertical layout would get you about 40% of the
> way there.
>
>        --- Pat
>
> > -----Original Message-----
> > From: Geoff Longman [mailto:glongman@gmail.com]
> > Sent: Monday, December 12, 2005 6:01 PM
> > To: Tapestry users
> > Subject: Re: Further simplifying Tapestry (was: tapestry to JSF
> > conversion)
> >
> > On 12/12/05, Paul Cantrell <ca...@pobox.com> wrote:
> > > > And wizards are helpful when you are not familiar with the
> > > > application of
> > > > the tool, they are a friendly introduction to doing something.
> > >
> > > Agreed, but ideally, the tool should be so elegant and self-
> > > explanatory that its natural interface is itself a friendly
> > > introduction. Obviously that's idealistic, but as ideals go, I think
> > > it's a good one.
> > >
> > > My point is really that if you find yourself building a wizard, you
> > > should first ask yourself what in your design makes a wizard
> > > necessary, and see if can be simplified.
> >
> > Ok, I'll jump into this one with both feet using Tap3 and Spindle as an
> > example.
> >
> > The new Component Wizard...oi
> >
> > In the default configuration you enter a name, have the option of
> > choosing a project/namespace, indicate that a template should be
> > generated (or not) .
> >
> > Pretty simple. The component is generated into the default location in
> > the application - context/WEB-INF (for application, colocated with a
> > library file if not) I believe off the top of my head.
> >
> > If one does not move to the second page, the component will be
> > specificed to use the BaseComponent as a class. The second page is
> > choose a class/create a class - not worth discussing.
> >
> > However the first page has grown into a morass of crud because there
> > are so many different places one can put things. So much stuff that I
> > had to add a Show/Hide advanced options button. Put it anywhere you
> > want and the wizard will update the .application/.library file if
> > necessary.
> > Use a custom template to generate the spec/template if you like.
> >
> > It's messy and I've deliberately avoided adding more features as I'm
> > of the belief the wizard was becoming LESS useful the more doodads
> > were added.
> >
> > I'm a long way off from the Tap 4 redo of the wizards and frankly I
> > think it's going to be worse (have no facts to back that up as of
> > yet).
> >
> > I know I know blah blah. The point is the more you want it to do, the
> > less useful it becomes (and more bug prone). And if you add everything
> > the people ask for the tool itself becomes an impediment to learning
> > the framework.
> >
> > Geoff
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>


--
The Spindle guy.           http://spindle.sf.net
Get help with Spindle:   
http://lists.sourceforge.net/mailman/listinfo/spindle-user
Announcement Feed:    
http://www.jroller.com/rss/glongman?catname=/Announcements
Feature Updates:            http://spindle.sf.net/updates

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org


Re: Further simplifying Tapestry (was: tapestry to JSF conversion)

Posted by Jesse Kuhnert <jk...@gmail.com>.
i know this is getting old....but it's the only wizard i've seen recently..

http://archive.dojotoolkit.org/nightly/tests/widget/test_Wizard.html

On 12/12/05, Patrick Casey <pa...@adelphia.net> wrote:
>
>
>         I'd love to see some sort of form generation wizard that was
> integrated with either hibernate or just a simple POJO.
>
>         e.g.
>
>         "Build me a form to display an example of <package>.<class>"
>
>         And then have the wizard introspect the class, determine the
> fields
> and types, and then create widgets as appropriate.
>
>         Nobody would use the result as an end product, but just getting
> the
> fields on the form in an ugly vertical layout would get you about 40% of
> the
> way there.
>
>         --- Pat
>
> > -----Original Message-----
> > From: Geoff Longman [mailto:glongman@gmail.com]
> > Sent: Monday, December 12, 2005 6:01 PM
> > To: Tapestry users
> > Subject: Re: Further simplifying Tapestry (was: tapestry to JSF
> > conversion)
> >
> > On 12/12/05, Paul Cantrell <ca...@pobox.com> wrote:
> > > > And wizards are helpful when you are not familiar with the
> > > > application of
> > > > the tool, they are a friendly introduction to doing something.
> > >
> > > Agreed, but ideally, the tool should be so elegant and self-
> > > explanatory that its natural interface is itself a friendly
> > > introduction. Obviously that's idealistic, but as ideals go, I think
> > > it's a good one.
> > >
> > > My point is really that if you find yourself building a wizard, you
> > > should first ask yourself what in your design makes a wizard
> > > necessary, and see if can be simplified.
> >
> > Ok, I'll jump into this one with both feet using Tap3 and Spindle as an
> > example.
> >
> > The new Component Wizard...oi
> >
> > In the default configuration you enter a name, have the option of
> > choosing a project/namespace, indicate that a template should be
> > generated (or not) .
> >
> > Pretty simple. The component is generated into the default location in
> > the application - context/WEB-INF (for application, colocated with a
> > library file if not) I believe off the top of my head.
> >
> > If one does not move to the second page, the component will be
> > specificed to use the BaseComponent as a class. The second page is
> > choose a class/create a class - not worth discussing.
> >
> > However the first page has grown into a morass of crud because there
> > are so many different places one can put things. So much stuff that I
> > had to add a Show/Hide advanced options button. Put it anywhere you
> > want and the wizard will update the .application/.library file if
> > necessary.
> > Use a custom template to generate the spec/template if you like.
> >
> > It's messy and I've deliberately avoided adding more features as I'm
> > of the belief the wizard was becoming LESS useful the more doodads
> > were added.
> >
> > I'm a long way off from the Tap 4 redo of the wizards and frankly I
> > think it's going to be worse (have no facts to back that up as of
> > yet).
> >
> > I know I know blah blah. The point is the more you want it to do, the
> > less useful it becomes (and more bug prone). And if you add everything
> > the people ask for the tool itself becomes an impediment to learning
> > the framework.
> >
> > Geoff
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>

RE: Further simplifying Tapestry (was: tapestry to JSF conversion)

Posted by Patrick Casey <pa...@adelphia.net>.
	I'd love to see some sort of form generation wizard that was
integrated with either hibernate or just a simple POJO.

	e.g.

	"Build me a form to display an example of <package>.<class>"

	And then have the wizard introspect the class, determine the fields
and types, and then create widgets as appropriate.

	Nobody would use the result as an end product, but just getting the
fields on the form in an ugly vertical layout would get you about 40% of the
way there.

	--- Pat

> -----Original Message-----
> From: Geoff Longman [mailto:glongman@gmail.com]
> Sent: Monday, December 12, 2005 6:01 PM
> To: Tapestry users
> Subject: Re: Further simplifying Tapestry (was: tapestry to JSF
> conversion)
> 
> On 12/12/05, Paul Cantrell <ca...@pobox.com> wrote:
> > > And wizards are helpful when you are not familiar with the
> > > application of
> > > the tool, they are a friendly introduction to doing something.
> >
> > Agreed, but ideally, the tool should be so elegant and self-
> > explanatory that its natural interface is itself a friendly
> > introduction. Obviously that's idealistic, but as ideals go, I think
> > it's a good one.
> >
> > My point is really that if you find yourself building a wizard, you
> > should first ask yourself what in your design makes a wizard
> > necessary, and see if can be simplified.
> 
> Ok, I'll jump into this one with both feet using Tap3 and Spindle as an
> example.
> 
> The new Component Wizard...oi
> 
> In the default configuration you enter a name, have the option of
> choosing a project/namespace, indicate that a template should be
> generated (or not) .
> 
> Pretty simple. The component is generated into the default location in
> the application - context/WEB-INF (for application, colocated with a
> library file if not) I believe off the top of my head.
> 
> If one does not move to the second page, the component will be
> specificed to use the BaseComponent as a class. The second page is
> choose a class/create a class - not worth discussing.
> 
> However the first page has grown into a morass of crud because there
> are so many different places one can put things. So much stuff that I
> had to add a Show/Hide advanced options button. Put it anywhere you
> want and the wizard will update the .application/.library file if
> necessary.
> Use a custom template to generate the spec/template if you like.
> 
> It's messy and I've deliberately avoided adding more features as I'm
> of the belief the wizard was becoming LESS useful the more doodads
> were added.
> 
> I'm a long way off from the Tap 4 redo of the wizards and frankly I
> think it's going to be worse (have no facts to back that up as of
> yet).
> 
> I know I know blah blah. The point is the more you want it to do, the
> less useful it becomes (and more bug prone). And if you add everything
> the people ask for the tool itself becomes an impediment to learning
> the framework.
> 
> Geoff
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org


Re: Further simplifying Tapestry (was: tapestry to JSF conversion)

Posted by Geoff Longman <gl...@gmail.com>.
On 12/12/05, Paul Cantrell <ca...@pobox.com> wrote:
> > And wizards are helpful when you are not familiar with the
> > application of
> > the tool, they are a friendly introduction to doing something.
>
> Agreed, but ideally, the tool should be so elegant and self-
> explanatory that its natural interface is itself a friendly
> introduction. Obviously that's idealistic, but as ideals go, I think
> it's a good one.
>
> My point is really that if you find yourself building a wizard, you
> should first ask yourself what in your design makes a wizard
> necessary, and see if can be simplified.

Ok, I'll jump into this one with both feet using Tap3 and Spindle as an example.

The new Component Wizard...oi

In the default configuration you enter a name, have the option of
choosing a project/namespace, indicate that a template should be
generated (or not) .

Pretty simple. The component is generated into the default location in
the application - context/WEB-INF (for application, colocated with a
library file if not) I believe off the top of my head.

If one does not move to the second page, the component will be
specificed to use the BaseComponent as a class. The second page is
choose a class/create a class - not worth discussing.

However the first page has grown into a morass of crud because there
are so many different places one can put things. So much stuff that I
had to add a Show/Hide advanced options button. Put it anywhere you
want and the wizard will update the .application/.library file if
necessary.
Use a custom template to generate the spec/template if you like.

It's messy and I've deliberately avoided adding more features as I'm
of the belief the wizard was becoming LESS useful the more doodads
were added.

I'm a long way off from the Tap 4 redo of the wizards and frankly I
think it's going to be worse (have no facts to back that up as of
yet).

I know I know blah blah. The point is the more you want it to do, the
less useful it becomes (and more bug prone). And if you add everything
the people ask for the tool itself becomes an impediment to learning
the framework.

Geoff

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org