You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Apache <ap...@ss78.shared.server-system.net> on 2006/03/03 13:04:44 UTC
How to improve Tapestry
I think Tapestry already makes a big step forward
but still there is a lot of things that could be made more dynamic and free programmers of templates and component definitions.
In my opinion everything could be in the database instead of configuration files.
In my idea world there should only be Java Classes
and no XML/Html/Page files.
I only want to tell the system to "genrate a form with the fields I tell you" and to tell it which fields are editable - the rest should be done automatically. Maybe you could tell how to order or align them, but I dont want to write any html templates.
-------------------- m2f --------------------
Sent from www.TapestryForums.com
Read this topic online here: <<topic_link>>
http://www.tapestryforums.com/viewtopic.php?p=14479#14479
-------------------- m2f --------------------
Re: How to improve Tapestry
Posted by James Carman <ja...@carmanconsulting.com>.
Try Trails! www.trailsframework.org
> I think Tapestry already makes a big step forward
> but still there is a lot of things that could be made more dynamic and
> free programmers of templates and component definitions.
>
> In my opinion everything could be in the database instead of configuration
> files.
>
> In my idea world there should only be Java Classes
> and no XML/Html/Page files.
>
> I only want to tell the system to "genrate a form with the fields I tell
> you" and to tell it which fields are editable - the rest should be done
> automatically. Maybe you could tell how to order or align them, but I dont
> want to write any html templates.
>
>
> -------------------- m2f --------------------
>
> Sent from www.TapestryForums.com
>
> Read this topic online here: <<topic_link>>
>
> http://www.tapestryforums.com/viewtopic.php?p=14479#14479
>
> -------------------- m2f --------------------
>
>
>
James Carman, President
Carman Consulting, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: How to improve Tapestry
Posted by John Coleman <jo...@ntlworld.com>.
This seems to me a departure from the Tapestry objective, as it is a
requirment for a form processing engine. So maybe Tapestry is a bad fit in
this case? Tools like Mandoforms do this kind of thing perhpas better, for a
price!
It might be useful to develop some Tap components to dynamically render and
process forms though? I've thought about this already, but Trails seems to
be a good starter.
John
> I only want to tell the system to "genrate a form with the fields I tell
you" and to tell it which fields are editable - the rest should be done
automatically. Maybe you could tell how to order or align them, but I dont
want to write any html templates.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: How to improve Tapestry
Posted by Pablo Ruggia <pr...@gmail.com>.
One year ago I've posted a solution to load your template from a database,
or generate it dynamically in Tapestry 3. I think that it wouldn't be too
different in T4.
When I say "dynamic", I only mean only once, because of the page pooling
thing. You can do a good abstraction to create your templates.
If tapestry wants to implement really dynamic form generation, it will have
to provide some way to mark a page as not poolable, or store components as
it do with persistent properties.
On 3/3/06, Apache <ap...@ss78.shared.server-system.net> wrote:
>
> I think Tapestry already makes a big step forward
> but still there is a lot of things that could be made more dynamic and
> free programmers of templates and component definitions.
>
> In my opinion everything could be in the database instead of configuration
> files.
>
> In my idea world there should only be Java Classes
> and no XML/Html/Page files.
>
> I only want to tell the system to "genrate a form with the fields I tell
> you" and to tell it which fields are editable - the rest should be done
> automatically. Maybe you could tell how to order or align them, but I dont
> want to write any html templates.
>
>
> -------------------- m2f --------------------
>
> Sent from www.TapestryForums.com
>
> Read this topic online here: <<topic_link>>
>
> http://www.tapestryforums.com/viewtopic.php?p=14479#14479
>
> -------------------- m2f --------------------
>
>
>
>
Re: How to improve Tapestry
Posted by Adam Zimowski <zi...@gmail.com>.
Question: if there were an exciting open source enterprise level web
application that is based on Tapestry (and also Spring), and which
could appeal to general public....
Would this be something that:
1) you'd consider in helping to grow (develop)
2) you'd consider as possibly a source of good documentation on Tapestry
Just curious.
On 3/3/06, Jason Suplizio <su...@gmail.com> wrote:
> I'm in the middle of a comprehensive review for my employer of our team's
> Tapestry experience. Although much praise went to Kent, Howard, and for all
> the help from the committers/developers on this list (thank you), the lack
> of documentation was a common theme through the evaluation (esp. Hivemind)
> that prevents us from expanding our adoption into other applications.
>
> But, hell, I worked on C#/VB .Net for the 2 years prior to this last year an
> lemme tell you, the MS documentation is horrible and often totally
> inaccurate. So, for not being the Sun or MS, the Tapestry team has an
> outstanding job and deserves serious kudos. The documentation short-comings,
> however, makes the learning curve feel infinitely steep.
>
>
> On 3/3/06, Peter Svensson <ps...@gmail.com> wrote:
> >
> > <agnostic>Amen!</agnostic> Could someone just for crying out loud at the
> > very least finish the api documentation with short examples on the main
> > site.
> > I would if I could but I can't so I won't.
> >
> > Sorry to be obnoxious.
> >
> > Cheers,
> > PS
> >
> > On 3/3/06, Mike.Barber@expeditors.com <Mi...@expeditors.com> wrote:
> > >
> > > Last month, I generated numerous e-mails on this list about dynamic
> > > components. After a lot of hair pulling, because a lot of tooth
> > pulling,
> > > I finally figured out how to do the whole block/for/if/db
> > solution. Yes,
> > > this solution is pretty annoying; especially to a dev who is more
> > > concerned about getting his product out the door than adhering to a
> > design
> > > dogma.
> > >
> > > However, I think the tragic flaw is not in the difficulty of the
> > > block/for/if solution, but in its lack of documentation. It seems to be
> > > well understood by a few Tapestry gurus, but a complex secret to us lay
> > > folks.
> > >
> > > I believe that Tapestry would be best served not by rushing to fix bugs
> > in
> > > 4.0 or forge ahead to 4.1, but by providing exhaustive
> > documentation--the
> > > majority of which should be examples. We spend *so much* time working
> > > through Tapestry's unique behavior because we have very few points of
> > > reference from which to draw. Tapestry in Action is a decent
> > start. Kent
> > > Tong's book is a better start (IMHO). But there needs to be more
> > > information. More examples. We've almost completely shelved the idea
> > of
> > > going to 4.0 for a long time (we're coding in 3.0.3) because we believe
> > it
> > > needs to stabilize AND because there are fewer examples available than
> > > 3.0.3. Why fight that battle anew?
> > >
> > > I've come to appreciate Tapestry & have found a certain amount of
> > > efficiency to it, but only after a steep learning curve and plenty of
> > > frustration. Two examples: dynamic components and application catalogs.
> > > Dynamic components is possible, but there's no clear set of examples or
> > > documentation. Application catalogs are documented, but don't
> > work. The
> > > workaround is *brutal*, but possible....if you're willing to go it
> > alone.
> > >
> > >
> > >
> > >
> > >
> > >
> > > "Todd Orr" <to...@gmail.com>
> > > 03/03/2006 08:45 AM
> > > Please respond to
> > > "Tapestry users" <ta...@jakarta.apache.org>
> > >
> > >
> > > To
> > > "Tapestry users" <ta...@jakarta.apache.org>
> > > cc
> > >
> > > Subject
> > > Re: How to improve Tapestry
> > >
> > >
> > >
> > >
> > >
> > >
> > > IMHO, the biggest feature that Tapestry is missing is solid dynamic
> > > component generation. Time and time again you'll see devs asking the
> > > same question in the forums, "how do I dynamically generate..." Each
> > > time someone points out the block, the for, or the if constructs. Yet
> > > these always seem way more difficult than they should be. Even with
> > > these tools, content management systems are notoriously difficult to
> > > build with Tapestry. Since Tapestry makes most things easier, this
> > > seems to be ironic. I began using Tapestry because most of my
> > > development time was cut in half, but the dynamic form development
> > > tasks I had to perform were tripled in time! Now, I could be the
> > > crappiest dev on earth, but I doubt it considering all the trouble
> > > everyone else has with this task and Tapestry. Because Tapestry is
> > > static, the very idea of dynamic components seems to leave a bad taste
> > > in Howard's mouth (and the mouths of die-hard enthusiasts). Yet it
> > > shouldn't, dynamic form generation is a very real, and fairly common
> > > task. It should be a first class citizen in the land of Tapestry.
> > >
> > > Just to make sure the tone of this post isn't misunderstood: I love
> > > Tapestry. Yet, everything can stand some measure of
> > > improvement/rethinking.
> > >
> > > On 3/3/06, Mark Stang <ms...@pingidentity.com> wrote:
> > > >
> > > > Look at http://www.nextapp.com (a.k.a. echo2).
> > > >
> > > > regards,
> > > >
> > > > Mark
> > > >
> > > > -----Original Message-----
> > > > From: Apache [mailto:apache@ss78.shared.server-system.net]
> > > > Sent: Fri 3/3/2006 5:04 AM
> > > > To: tapestry-user@jakarta.apache.org
> > > > Subject: How to improve Tapestry
> > > >
> > > > I think Tapestry already makes a big step forward
> > > > but still there is a lot of things that could be made more dynamic and
> > > free programmers of templates and component definitions.
> > > >
> > > > In my opinion everything could be in the database instead of
> > > configuration files.
> > > >
> > > > In my idea world there should only be Java Classes
> > > > and no XML/Html/Page files.
> > > >
> > > > I only want to tell the system to "genrate a form with the fields I
> > tell
> > > you" and to tell it which fields are editable - the rest should be done
> > > automatically. Maybe you could tell how to order or align them, but I
> > dont
> > > want to write any html templates.
> > > >
> > > >
> > > > -------------------- m2f --------------------
> > > >
> > > > Sent from www.TapestryForums.com
> > > >
> > > > Read this topic online here: <<topic_link>>
> > > >
> > > > http://www.tapestryforums.com/viewtopic.php?p=14479#14479
> > > >
> > > > -------------------- m2f --------------------
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > 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: How to improve Tapestry
Posted by adasal <ad...@gmail.com>.
>
> if there were an exciting open source enterprise level web
> application that is based on Tapestry (and also Spring), and which
> could appeal to general public....
Would I be interested? Yes.
About improving Tapestry.
I hadn't researched into forms processing apps, although what I have just
read here doesn't surprise me.
It came my way to consider such a possibility, actually much like the
original poster's comments.
I wondered how this might be achieved in tapestry. The general form of
development is to, somehow, take a schema and create an object model
around it and then write Tapestry (or other framework) over it. This is
often dictated by the customer. But it means that each class is made up of
several fields, each with their own name, and attached to their own class,
while the actual fields are nothing but a text field or what ever.
In many circumstances it would be more useful to distinguish each field on
the basis of what it does in its context, that is should the contents be
taken in conjunction with other contents that have just been entered and if
so, how?
A unique name doesn't supply this information! But, and I note other posts
on this list, semantic information would. So my thinking is that a way to
forward Tapestry would be to enable semantic descriptions of objects and
this would determine how they are processed.We should remember that Tapestry
is not wedded to hibernate or what ever, it would be possible to have an
intervening semantic layer and this could obviate some of the problems that
exist in tapestry, or for this way of populating dbs. wrt Tapestry I wonder
if this might be a way of attaching an id to an as yet to be rendered table
within a table, I speculate? wrt dbs, might using OWL or RDF stores avoid
the problem of fighting over field sizes that often happens when translating
an XML schema into tables, again, I speculate?
Anyway, thoughts,
Best,
Adam
On 03/03/06, adasal <ad...@gmail.com> wrote:
>
> em. My experience working with Tapestry and hivemind has not been a lack
> of documentation. What I found is that there is a play off between time
> spent on following an example and actually experimenting in code. If there
> were more documentation there would be a potential greater time sink since
> it is not possible to document every scenario. There are complex and
> confusing issues at first especially such as the choice between implicit,
> explicit XML and property injection of a component etc.
> Between Tapestry and Hivemind each requires its own way of working. With
> Hivemind I found I had to make frequent refence to the DTD. Not so with
> Tapestry. With Hivemind it is as well to bear in mind that you are pushing
> to a stack (order maybe significant) while ids direct flow between stanzas.
> There is little that can't be achieved with Hivemind if you build your own
> object translators, though getting too complex defeats the point.
> Our team has also not found a transition from T3.1 to T4.1(?) particularly
> painful. Tapestry lives up to its promise of modularisation of development,
> encouraging working on discrete tasks and allowing people to pass from task
> to task. Because of this it allows maintenance of code and folding in of
> changes. These are huge gains.
> I post separately on improving tapestry.
> Adam Saltiel
>
> On 03/03/06, Jason Suplizio <su...@gmail.com> wrote:
> >
> > I'm in the middle of a comprehensive review for my employer of our
> > team's
> > Tapestry experience. Although much praise went to Kent, Howard, and for
> > all
> > the help from the committers/developers on this list (thank you), the
> > lack
> > of documentation was a common theme through the evaluation (esp.
> > Hivemind)
> > that prevents us from expanding our adoption into other applications.
> >
> > But, hell, I worked on C#/VB .Net for the 2 years prior to this last
> > year an
> > lemme tell you, the MS documentation is horrible and often totally
> > inaccurate. So, for not being the Sun or MS, the Tapestry team has an
> > outstanding job and deserves serious kudos. The documentation
> > short-comings,
> > however, makes the learning curve feel infinitely steep.
> >
> >
> > On 3/3/06, Peter Svensson <ps...@gmail.com> wrote:
> > >
> > > <agnostic>Amen!</agnostic> Could someone just for crying out loud at
> > the
> > > very least finish the api documentation with short examples on the
> > main
> > > site.
> > > I would if I could but I can't so I won't.
> > >
> > > Sorry to be obnoxious.
> > >
> > > Cheers,
> > > PS
> > >
> > > On 3/3/06, Mike.Barber@expeditors.com <Mi...@expeditors.com>
> > wrote:
> > > >
> > > > Last month, I generated numerous e-mails on this list about dynamic
> > > > components. After a lot of hair pulling, because a lot of tooth
> > > pulling,
> > > > I finally figured out how to do the whole block/for/if/db
> > > solution. Yes,
> > > > this solution is pretty annoying; especially to a dev who is more
> > > > concerned about getting his product out the door than adhering to a
> > > design
> > > > dogma.
> > > >
> > > > However, I think the tragic flaw is not in the difficulty of the
> > > > block/for/if solution, but in its lack of documentation. It seems
> > to be
> > > > well understood by a few Tapestry gurus, but a complex secret to us
> > lay
> > > > folks.
> > > >
> > > > I believe that Tapestry would be best served not by rushing to fix
> > bugs
> > > in
> > > > 4.0 or forge ahead to 4.1, but by providing exhaustive
> > > documentation--the
> > > > majority of which should be examples. We spend *so much* time
> > working
> > > > through Tapestry's unique behavior because we have very few points
> > of
> > > > reference from which to draw. Tapestry in Action is a decent
> > > start. Kent
> > > > Tong's book is a better start (IMHO). But there needs to be more
> > > > information. More examples. We've almost completely shelved the
> > idea
> > > of
> > > > going to 4.0 for a long time (we're coding in 3.0.3) because we
> > believe
> > > it
> > > > needs to stabilize AND because there are fewer examples available
> > than
> > > > 3.0.3. Why fight that battle anew?
> > > >
> > > > I've come to appreciate Tapestry & have found a certain amount of
> > > > efficiency to it, but only after a steep learning curve and plenty
> > of
> > > > frustration. Two examples: dynamic components and application
> > catalogs.
> > > > Dynamic components is possible, but there's no clear set of examples
> > or
> > > > documentation. Application catalogs are documented, but don't
> > > work. The
> > > > workaround is *brutal*, but possible....if you're willing to go it
> > > alone.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > "Todd Orr" <to...@gmail.com>
> > > > 03/03/2006 08:45 AM
> > > > Please respond to
> > > > "Tapestry users" <ta...@jakarta.apache.org>
> > > >
> > > >
> > > > To
> > > > "Tapestry users" < tapestry-user@jakarta.apache.org>
> > > > cc
> > > >
> > > > Subject
> > > > Re: How to improve Tapestry
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > IMHO, the biggest feature that Tapestry is missing is solid dynamic
> > > > component generation. Time and time again you'll see devs asking the
> > > > same question in the forums, "how do I dynamically generate..." Each
> >
> > > > time someone points out the block, the for, or the if constructs.
> > Yet
> > > > these always seem way more difficult than they should be. Even with
> > > > these tools, content management systems are notoriously difficult to
> >
> > > > build with Tapestry. Since Tapestry makes most things easier, this
> > > > seems to be ironic. I began using Tapestry because most of my
> > > > development time was cut in half, but the dynamic form development
> > > > tasks I had to perform were tripled in time! Now, I could be the
> > > > crappiest dev on earth, but I doubt it considering all the trouble
> > > > everyone else has with this task and Tapestry. Because Tapestry is
> > > > static, the very idea of dynamic components seems to leave a bad
> > taste
> > > > in Howard's mouth (and the mouths of die-hard enthusiasts). Yet it
> > > > shouldn't, dynamic form generation is a very real, and fairly common
> >
> > > > task. It should be a first class citizen in the land of Tapestry.
> > > >
> > > > Just to make sure the tone of this post isn't misunderstood: I love
> > > > Tapestry. Yet, everything can stand some measure of
> > > > improvement/rethinking.
> > > >
> > > > On 3/3/06, Mark Stang <ms...@pingidentity.com> wrote:
> > > > >
> > > > > Look at http://www.nextapp.com (a.k.a. echo2).
> > > > >
> > > > > regards,
> > > > >
> > > > > Mark
> > > > >
> > > > > -----Original Message-----
> > > > > From: Apache [mailto: apache@ss78.shared.server-system.net]
> > > > > Sent: Fri 3/3/2006 5:04 AM
> > > > > To: tapestry-user@jakarta.apache.org
> > > > > Subject: How to improve Tapestry
> > > > >
> > > > > I think Tapestry already makes a big step forward
> > > > > but still there is a lot of things that could be made more dynamic
> > and
> > > > free programmers of templates and component definitions.
> > > > >
> > > > > In my opinion everything could be in the database instead of
> > > > configuration files.
> > > > >
> > > > > In my idea world there should only be Java Classes
> > > > > and no XML/Html/Page files.
> > > > >
> > > > > I only want to tell the system to "genrate a form with the fields
> > I
> > > tell
> > > > you" and to tell it which fields are editable - the rest should be
> > done
> > > > automatically. Maybe you could tell how to order or align them, but
> > I
> > > dont
> > > > want to write any html templates.
> > > > >
> > > > >
> > > > > -------------------- m2f --------------------
> > > > >
> > > > > Sent from www.TapestryForums.com
> > > > >
> > > > > Read this topic online here: <<topic_link>>
> > > > >
> > > > > http://www.tapestryforums.com/viewtopic.php?p=14479#14479
> > > > >
> > > > > -------------------- m2f --------------------
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> > tapestry-user-help@jakarta.apache.org
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
Re: How to improve Tapestry
Posted by adasal <ad...@gmail.com>.
em. My experience working with Tapestry and hivemind has not been a lack of
documentation. What I found is that there is a play off between time spent
on following an example and actually experimenting in code. If there were
more documentation there would be a potential greater time sink since it is
not possible to document every scenario. There are complex and confusing
issues at first especially such as the choice between implicit, explicit XML
and property injection of a component etc.
Between Tapestry and Hivemind each requires its own way of working. With
Hivemind I found I had to make frequent refence to the DTD. Not so with
Tapestry. With Hivemind it is as well to bear in mind that you are pushing
to a stack (order maybe significant) while ids direct flow between stanzas.
There is little that can't be achieved with Hivemind if you build your own
object translators, though getting too complex defeats the point.
Our team has also not found a transition from T3.1 to T4.1(?) particularly
painful. Tapestry lives up to its promise of modularisation of development,
encouraging working on discrete tasks and allowing people to pass from task
to task. Because of this it allows maintenance of code and folding in of
changes. These are huge gains.
I post separately on improving tapestry.
Adam Saltiel
On 03/03/06, Jason Suplizio <su...@gmail.com> wrote:
>
> I'm in the middle of a comprehensive review for my employer of our team's
> Tapestry experience. Although much praise went to Kent, Howard, and for
> all
> the help from the committers/developers on this list (thank you), the lack
> of documentation was a common theme through the evaluation (esp. Hivemind)
> that prevents us from expanding our adoption into other applications.
>
> But, hell, I worked on C#/VB .Net for the 2 years prior to this last year
> an
> lemme tell you, the MS documentation is horrible and often totally
> inaccurate. So, for not being the Sun or MS, the Tapestry team has an
> outstanding job and deserves serious kudos. The documentation
> short-comings,
> however, makes the learning curve feel infinitely steep.
>
>
> On 3/3/06, Peter Svensson <ps...@gmail.com> wrote:
> >
> > <agnostic>Amen!</agnostic> Could someone just for crying out loud at
> the
> > very least finish the api documentation with short examples on the main
> > site.
> > I would if I could but I can't so I won't.
> >
> > Sorry to be obnoxious.
> >
> > Cheers,
> > PS
> >
> > On 3/3/06, Mike.Barber@expeditors.com <Mi...@expeditors.com>
> wrote:
> > >
> > > Last month, I generated numerous e-mails on this list about dynamic
> > > components. After a lot of hair pulling, because a lot of tooth
> > pulling,
> > > I finally figured out how to do the whole block/for/if/db
> > solution. Yes,
> > > this solution is pretty annoying; especially to a dev who is more
> > > concerned about getting his product out the door than adhering to a
> > design
> > > dogma.
> > >
> > > However, I think the tragic flaw is not in the difficulty of the
> > > block/for/if solution, but in its lack of documentation. It seems to
> be
> > > well understood by a few Tapestry gurus, but a complex secret to us
> lay
> > > folks.
> > >
> > > I believe that Tapestry would be best served not by rushing to fix
> bugs
> > in
> > > 4.0 or forge ahead to 4.1, but by providing exhaustive
> > documentation--the
> > > majority of which should be examples. We spend *so much* time working
> > > through Tapestry's unique behavior because we have very few points of
> > > reference from which to draw. Tapestry in Action is a decent
> > start. Kent
> > > Tong's book is a better start (IMHO). But there needs to be more
> > > information. More examples. We've almost completely shelved the idea
> > of
> > > going to 4.0 for a long time (we're coding in 3.0.3) because we
> believe
> > it
> > > needs to stabilize AND because there are fewer examples available than
> > > 3.0.3. Why fight that battle anew?
> > >
> > > I've come to appreciate Tapestry & have found a certain amount of
> > > efficiency to it, but only after a steep learning curve and plenty of
> > > frustration. Two examples: dynamic components and application
> catalogs.
> > > Dynamic components is possible, but there's no clear set of examples
> or
> > > documentation. Application catalogs are documented, but don't
> > work. The
> > > workaround is *brutal*, but possible....if you're willing to go it
> > alone.
> > >
> > >
> > >
> > >
> > >
> > >
> > > "Todd Orr" <to...@gmail.com>
> > > 03/03/2006 08:45 AM
> > > Please respond to
> > > "Tapestry users" <ta...@jakarta.apache.org>
> > >
> > >
> > > To
> > > "Tapestry users" <ta...@jakarta.apache.org>
> > > cc
> > >
> > > Subject
> > > Re: How to improve Tapestry
> > >
> > >
> > >
> > >
> > >
> > >
> > > IMHO, the biggest feature that Tapestry is missing is solid dynamic
> > > component generation. Time and time again you'll see devs asking the
> > > same question in the forums, "how do I dynamically generate..." Each
> > > time someone points out the block, the for, or the if constructs. Yet
> > > these always seem way more difficult than they should be. Even with
> > > these tools, content management systems are notoriously difficult to
> > > build with Tapestry. Since Tapestry makes most things easier, this
> > > seems to be ironic. I began using Tapestry because most of my
> > > development time was cut in half, but the dynamic form development
> > > tasks I had to perform were tripled in time! Now, I could be the
> > > crappiest dev on earth, but I doubt it considering all the trouble
> > > everyone else has with this task and Tapestry. Because Tapestry is
> > > static, the very idea of dynamic components seems to leave a bad taste
> > > in Howard's mouth (and the mouths of die-hard enthusiasts). Yet it
> > > shouldn't, dynamic form generation is a very real, and fairly common
> > > task. It should be a first class citizen in the land of Tapestry.
> > >
> > > Just to make sure the tone of this post isn't misunderstood: I love
> > > Tapestry. Yet, everything can stand some measure of
> > > improvement/rethinking.
> > >
> > > On 3/3/06, Mark Stang <ms...@pingidentity.com> wrote:
> > > >
> > > > Look at http://www.nextapp.com (a.k.a. echo2).
> > > >
> > > > regards,
> > > >
> > > > Mark
> > > >
> > > > -----Original Message-----
> > > > From: Apache [mailto:apache@ss78.shared.server-system.net]
> > > > Sent: Fri 3/3/2006 5:04 AM
> > > > To: tapestry-user@jakarta.apache.org
> > > > Subject: How to improve Tapestry
> > > >
> > > > I think Tapestry already makes a big step forward
> > > > but still there is a lot of things that could be made more dynamic
> and
> > > free programmers of templates and component definitions.
> > > >
> > > > In my opinion everything could be in the database instead of
> > > configuration files.
> > > >
> > > > In my idea world there should only be Java Classes
> > > > and no XML/Html/Page files.
> > > >
> > > > I only want to tell the system to "genrate a form with the fields I
> > tell
> > > you" and to tell it which fields are editable - the rest should be
> done
> > > automatically. Maybe you could tell how to order or align them, but I
> > dont
> > > want to write any html templates.
> > > >
> > > >
> > > > -------------------- m2f --------------------
> > > >
> > > > Sent from www.TapestryForums.com
> > > >
> > > > Read this topic online here: <<topic_link>>
> > > >
> > > > http://www.tapestryforums.com/viewtopic.php?p=14479#14479
> > > >
> > > > -------------------- m2f --------------------
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> > >
> > >
> > >
> > >
> >
> >
>
>
RE: How to improve Tapestry
Posted by James Carman <ja...@carmanconsulting.com>.
Could there at least be a link from the Table and Tree components'
documentation page to John Reynolds's Blog
(http://weblogs.java.net/blog/johnreynolds/archive/2004/10/learn_by_teachi_1
.html)?
The war files you can download from there are pretty nice. The component
documentation pages are utterly useless.
-----Original Message-----
From: Jason Suplizio [mailto:suplizio@gmail.com]
Sent: Friday, March 03, 2006 2:41 PM
To: Tapestry users
Subject: Re: How to improve Tapestry
I'm in the middle of a comprehensive review for my employer of our team's
Tapestry experience. Although much praise went to Kent, Howard, and for all
the help from the committers/developers on this list (thank you), the lack
of documentation was a common theme through the evaluation (esp. Hivemind)
that prevents us from expanding our adoption into other applications.
But, hell, I worked on C#/VB .Net for the 2 years prior to this last year an
lemme tell you, the MS documentation is horrible and often totally
inaccurate. So, for not being the Sun or MS, the Tapestry team has an
outstanding job and deserves serious kudos. The documentation short-comings,
however, makes the learning curve feel infinitely steep.
On 3/3/06, Peter Svensson <ps...@gmail.com> wrote:
>
> <agnostic>Amen!</agnostic> Could someone just for crying out loud at the
> very least finish the api documentation with short examples on the main
> site.
> I would if I could but I can't so I won't.
>
> Sorry to be obnoxious.
>
> Cheers,
> PS
>
> On 3/3/06, Mike.Barber@expeditors.com <Mi...@expeditors.com> wrote:
> >
> > Last month, I generated numerous e-mails on this list about dynamic
> > components. After a lot of hair pulling, because a lot of tooth
> pulling,
> > I finally figured out how to do the whole block/for/if/db
> solution. Yes,
> > this solution is pretty annoying; especially to a dev who is more
> > concerned about getting his product out the door than adhering to a
> design
> > dogma.
> >
> > However, I think the tragic flaw is not in the difficulty of the
> > block/for/if solution, but in its lack of documentation. It seems to be
> > well understood by a few Tapestry gurus, but a complex secret to us lay
> > folks.
> >
> > I believe that Tapestry would be best served not by rushing to fix bugs
> in
> > 4.0 or forge ahead to 4.1, but by providing exhaustive
> documentation--the
> > majority of which should be examples. We spend *so much* time working
> > through Tapestry's unique behavior because we have very few points of
> > reference from which to draw. Tapestry in Action is a decent
> start. Kent
> > Tong's book is a better start (IMHO). But there needs to be more
> > information. More examples. We've almost completely shelved the idea
> of
> > going to 4.0 for a long time (we're coding in 3.0.3) because we believe
> it
> > needs to stabilize AND because there are fewer examples available than
> > 3.0.3. Why fight that battle anew?
> >
> > I've come to appreciate Tapestry & have found a certain amount of
> > efficiency to it, but only after a steep learning curve and plenty of
> > frustration. Two examples: dynamic components and application catalogs.
> > Dynamic components is possible, but there's no clear set of examples or
> > documentation. Application catalogs are documented, but don't
> work. The
> > workaround is *brutal*, but possible....if you're willing to go it
> alone.
> >
> >
> >
> >
> >
> >
> > "Todd Orr" <to...@gmail.com>
> > 03/03/2006 08:45 AM
> > Please respond to
> > "Tapestry users" <ta...@jakarta.apache.org>
> >
> >
> > To
> > "Tapestry users" <ta...@jakarta.apache.org>
> > cc
> >
> > Subject
> > Re: How to improve Tapestry
> >
> >
> >
> >
> >
> >
> > IMHO, the biggest feature that Tapestry is missing is solid dynamic
> > component generation. Time and time again you'll see devs asking the
> > same question in the forums, "how do I dynamically generate..." Each
> > time someone points out the block, the for, or the if constructs. Yet
> > these always seem way more difficult than they should be. Even with
> > these tools, content management systems are notoriously difficult to
> > build with Tapestry. Since Tapestry makes most things easier, this
> > seems to be ironic. I began using Tapestry because most of my
> > development time was cut in half, but the dynamic form development
> > tasks I had to perform were tripled in time! Now, I could be the
> > crappiest dev on earth, but I doubt it considering all the trouble
> > everyone else has with this task and Tapestry. Because Tapestry is
> > static, the very idea of dynamic components seems to leave a bad taste
> > in Howard's mouth (and the mouths of die-hard enthusiasts). Yet it
> > shouldn't, dynamic form generation is a very real, and fairly common
> > task. It should be a first class citizen in the land of Tapestry.
> >
> > Just to make sure the tone of this post isn't misunderstood: I love
> > Tapestry. Yet, everything can stand some measure of
> > improvement/rethinking.
> >
> > On 3/3/06, Mark Stang <ms...@pingidentity.com> wrote:
> > >
> > > Look at http://www.nextapp.com (a.k.a. echo2).
> > >
> > > regards,
> > >
> > > Mark
> > >
> > > -----Original Message-----
> > > From: Apache [mailto:apache@ss78.shared.server-system.net]
> > > Sent: Fri 3/3/2006 5:04 AM
> > > To: tapestry-user@jakarta.apache.org
> > > Subject: How to improve Tapestry
> > >
> > > I think Tapestry already makes a big step forward
> > > but still there is a lot of things that could be made more dynamic and
> > free programmers of templates and component definitions.
> > >
> > > In my opinion everything could be in the database instead of
> > configuration files.
> > >
> > > In my idea world there should only be Java Classes
> > > and no XML/Html/Page files.
> > >
> > > I only want to tell the system to "genrate a form with the fields I
> tell
> > you" and to tell it which fields are editable - the rest should be done
> > automatically. Maybe you could tell how to order or align them, but I
> dont
> > want to write any html templates.
> > >
> > >
> > > -------------------- m2f --------------------
> > >
> > > Sent from www.TapestryForums.com
> > >
> > > Read this topic online here: <<topic_link>>
> > >
> > > http://www.tapestryforums.com/viewtopic.php?p=14479#14479
> > >
> > > -------------------- m2f --------------------
> > >
> > >
> > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > 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: How to improve Tapestry
Posted by Jason Suplizio <su...@gmail.com>.
I'm in the middle of a comprehensive review for my employer of our team's
Tapestry experience. Although much praise went to Kent, Howard, and for all
the help from the committers/developers on this list (thank you), the lack
of documentation was a common theme through the evaluation (esp. Hivemind)
that prevents us from expanding our adoption into other applications.
But, hell, I worked on C#/VB .Net for the 2 years prior to this last year an
lemme tell you, the MS documentation is horrible and often totally
inaccurate. So, for not being the Sun or MS, the Tapestry team has an
outstanding job and deserves serious kudos. The documentation short-comings,
however, makes the learning curve feel infinitely steep.
On 3/3/06, Peter Svensson <ps...@gmail.com> wrote:
>
> <agnostic>Amen!</agnostic> Could someone just for crying out loud at the
> very least finish the api documentation with short examples on the main
> site.
> I would if I could but I can't so I won't.
>
> Sorry to be obnoxious.
>
> Cheers,
> PS
>
> On 3/3/06, Mike.Barber@expeditors.com <Mi...@expeditors.com> wrote:
> >
> > Last month, I generated numerous e-mails on this list about dynamic
> > components. After a lot of hair pulling, because a lot of tooth
> pulling,
> > I finally figured out how to do the whole block/for/if/db
> solution. Yes,
> > this solution is pretty annoying; especially to a dev who is more
> > concerned about getting his product out the door than adhering to a
> design
> > dogma.
> >
> > However, I think the tragic flaw is not in the difficulty of the
> > block/for/if solution, but in its lack of documentation. It seems to be
> > well understood by a few Tapestry gurus, but a complex secret to us lay
> > folks.
> >
> > I believe that Tapestry would be best served not by rushing to fix bugs
> in
> > 4.0 or forge ahead to 4.1, but by providing exhaustive
> documentation--the
> > majority of which should be examples. We spend *so much* time working
> > through Tapestry's unique behavior because we have very few points of
> > reference from which to draw. Tapestry in Action is a decent
> start. Kent
> > Tong's book is a better start (IMHO). But there needs to be more
> > information. More examples. We've almost completely shelved the idea
> of
> > going to 4.0 for a long time (we're coding in 3.0.3) because we believe
> it
> > needs to stabilize AND because there are fewer examples available than
> > 3.0.3. Why fight that battle anew?
> >
> > I've come to appreciate Tapestry & have found a certain amount of
> > efficiency to it, but only after a steep learning curve and plenty of
> > frustration. Two examples: dynamic components and application catalogs.
> > Dynamic components is possible, but there's no clear set of examples or
> > documentation. Application catalogs are documented, but don't
> work. The
> > workaround is *brutal*, but possible....if you're willing to go it
> alone.
> >
> >
> >
> >
> >
> >
> > "Todd Orr" <to...@gmail.com>
> > 03/03/2006 08:45 AM
> > Please respond to
> > "Tapestry users" <ta...@jakarta.apache.org>
> >
> >
> > To
> > "Tapestry users" <ta...@jakarta.apache.org>
> > cc
> >
> > Subject
> > Re: How to improve Tapestry
> >
> >
> >
> >
> >
> >
> > IMHO, the biggest feature that Tapestry is missing is solid dynamic
> > component generation. Time and time again you'll see devs asking the
> > same question in the forums, "how do I dynamically generate..." Each
> > time someone points out the block, the for, or the if constructs. Yet
> > these always seem way more difficult than they should be. Even with
> > these tools, content management systems are notoriously difficult to
> > build with Tapestry. Since Tapestry makes most things easier, this
> > seems to be ironic. I began using Tapestry because most of my
> > development time was cut in half, but the dynamic form development
> > tasks I had to perform were tripled in time! Now, I could be the
> > crappiest dev on earth, but I doubt it considering all the trouble
> > everyone else has with this task and Tapestry. Because Tapestry is
> > static, the very idea of dynamic components seems to leave a bad taste
> > in Howard's mouth (and the mouths of die-hard enthusiasts). Yet it
> > shouldn't, dynamic form generation is a very real, and fairly common
> > task. It should be a first class citizen in the land of Tapestry.
> >
> > Just to make sure the tone of this post isn't misunderstood: I love
> > Tapestry. Yet, everything can stand some measure of
> > improvement/rethinking.
> >
> > On 3/3/06, Mark Stang <ms...@pingidentity.com> wrote:
> > >
> > > Look at http://www.nextapp.com (a.k.a. echo2).
> > >
> > > regards,
> > >
> > > Mark
> > >
> > > -----Original Message-----
> > > From: Apache [mailto:apache@ss78.shared.server-system.net]
> > > Sent: Fri 3/3/2006 5:04 AM
> > > To: tapestry-user@jakarta.apache.org
> > > Subject: How to improve Tapestry
> > >
> > > I think Tapestry already makes a big step forward
> > > but still there is a lot of things that could be made more dynamic and
> > free programmers of templates and component definitions.
> > >
> > > In my opinion everything could be in the database instead of
> > configuration files.
> > >
> > > In my idea world there should only be Java Classes
> > > and no XML/Html/Page files.
> > >
> > > I only want to tell the system to "genrate a form with the fields I
> tell
> > you" and to tell it which fields are editable - the rest should be done
> > automatically. Maybe you could tell how to order or align them, but I
> dont
> > want to write any html templates.
> > >
> > >
> > > -------------------- m2f --------------------
> > >
> > > Sent from www.TapestryForums.com
> > >
> > > Read this topic online here: <<topic_link>>
> > >
> > > http://www.tapestryforums.com/viewtopic.php?p=14479#14479
> > >
> > > -------------------- m2f --------------------
> > >
> > >
> > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
> >
> >
>
>
Re: How to improve Tapestry
Posted by Peter Svensson <ps...@gmail.com>.
<agnostic>Amen!</agnostic> Could someone just for crying out loud at the
very least finish the api documentation with short examples on the main
site.
I would if I could but I can't so I won't.
Sorry to be obnoxious.
Cheers,
PS
On 3/3/06, Mike.Barber@expeditors.com <Mi...@expeditors.com> wrote:
>
> Last month, I generated numerous e-mails on this list about dynamic
> components. After a lot of hair pulling, because a lot of tooth pulling,
> I finally figured out how to do the whole block/for/if/db solution. Yes,
> this solution is pretty annoying; especially to a dev who is more
> concerned about getting his product out the door than adhering to a design
> dogma.
>
> However, I think the tragic flaw is not in the difficulty of the
> block/for/if solution, but in its lack of documentation. It seems to be
> well understood by a few Tapestry gurus, but a complex secret to us lay
> folks.
>
> I believe that Tapestry would be best served not by rushing to fix bugs in
> 4.0 or forge ahead to 4.1, but by providing exhaustive documentation--the
> majority of which should be examples. We spend *so much* time working
> through Tapestry's unique behavior because we have very few points of
> reference from which to draw. Tapestry in Action is a decent start. Kent
> Tong's book is a better start (IMHO). But there needs to be more
> information. More examples. We've almost completely shelved the idea of
> going to 4.0 for a long time (we're coding in 3.0.3) because we believe it
> needs to stabilize AND because there are fewer examples available than
> 3.0.3. Why fight that battle anew?
>
> I've come to appreciate Tapestry & have found a certain amount of
> efficiency to it, but only after a steep learning curve and plenty of
> frustration. Two examples: dynamic components and application catalogs.
> Dynamic components is possible, but there's no clear set of examples or
> documentation. Application catalogs are documented, but don't work. The
> workaround is *brutal*, but possible....if you're willing to go it alone.
>
>
>
>
>
>
> "Todd Orr" <to...@gmail.com>
> 03/03/2006 08:45 AM
> Please respond to
> "Tapestry users" <ta...@jakarta.apache.org>
>
>
> To
> "Tapestry users" <ta...@jakarta.apache.org>
> cc
>
> Subject
> Re: How to improve Tapestry
>
>
>
>
>
>
> IMHO, the biggest feature that Tapestry is missing is solid dynamic
> component generation. Time and time again you'll see devs asking the
> same question in the forums, "how do I dynamically generate..." Each
> time someone points out the block, the for, or the if constructs. Yet
> these always seem way more difficult than they should be. Even with
> these tools, content management systems are notoriously difficult to
> build with Tapestry. Since Tapestry makes most things easier, this
> seems to be ironic. I began using Tapestry because most of my
> development time was cut in half, but the dynamic form development
> tasks I had to perform were tripled in time! Now, I could be the
> crappiest dev on earth, but I doubt it considering all the trouble
> everyone else has with this task and Tapestry. Because Tapestry is
> static, the very idea of dynamic components seems to leave a bad taste
> in Howard's mouth (and the mouths of die-hard enthusiasts). Yet it
> shouldn't, dynamic form generation is a very real, and fairly common
> task. It should be a first class citizen in the land of Tapestry.
>
> Just to make sure the tone of this post isn't misunderstood: I love
> Tapestry. Yet, everything can stand some measure of
> improvement/rethinking.
>
> On 3/3/06, Mark Stang <ms...@pingidentity.com> wrote:
> >
> > Look at http://www.nextapp.com (a.k.a. echo2).
> >
> > regards,
> >
> > Mark
> >
> > -----Original Message-----
> > From: Apache [mailto:apache@ss78.shared.server-system.net]
> > Sent: Fri 3/3/2006 5:04 AM
> > To: tapestry-user@jakarta.apache.org
> > Subject: How to improve Tapestry
> >
> > I think Tapestry already makes a big step forward
> > but still there is a lot of things that could be made more dynamic and
> free programmers of templates and component definitions.
> >
> > In my opinion everything could be in the database instead of
> configuration files.
> >
> > In my idea world there should only be Java Classes
> > and no XML/Html/Page files.
> >
> > I only want to tell the system to "genrate a form with the fields I tell
> you" and to tell it which fields are editable - the rest should be done
> automatically. Maybe you could tell how to order or align them, but I dont
> want to write any html templates.
> >
> >
> > -------------------- m2f --------------------
> >
> > Sent from www.TapestryForums.com
> >
> > Read this topic online here: <<topic_link>>
> >
> > http://www.tapestryforums.com/viewtopic.php?p=14479#14479
> >
> > -------------------- m2f --------------------
> >
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
>
Re: How to improve Tapestry
Posted by Stephen Todd <st...@agilestudios.com>.
I have been considering a solution to this, which I don't think would
change too much. The idea is that we have a component pool much like
we have a page pool. When the template is loaded, the components are
read in so they are ready. So instead of referencing them by object
in memory, they could be referenced by name. All instances of the
component should be the same anyway. The increased cost in time would
be in the look up having to pull them from a pool of components and
not through direct references.
You could even have the option to not use page components and have
them created automatically if you link to a component. You would have
access to the page from the component and specify required things
(ie CSS files) needed in the head tags, and then if they are not
already there, it would add them.
There may be some things I am missing, but I think it could be done
and much of the structure of the current code looks like it could be
done without having to change the entire project.
Just a thought because I agree with the parent's assessment.
Stephen
On Mar 3, 2006, at 9:45 AM, Todd Orr wrote:
> IMHO, the biggest feature that Tapestry is missing is solid dynamic
> component generation. Time and time again you'll see devs asking the
> same question in the forums, "how do I dynamically generate..." Each
> time someone points out the block, the for, or the if constructs. Yet
> these always seem way more difficult than they should be. Even with
> these tools, content management systems are notoriously difficult to
> build with Tapestry. Since Tapestry makes most things easier, this
> seems to be ironic. I began using Tapestry because most of my
> development time was cut in half, but the dynamic form development
> tasks I had to perform were tripled in time! Now, I could be the
> crappiest dev on earth, but I doubt it considering all the trouble
> everyone else has with this task and Tapestry. Because Tapestry is
> static, the very idea of dynamic components seems to leave a bad taste
> in Howard's mouth (and the mouths of die-hard enthusiasts). Yet it
> shouldn't, dynamic form generation is a very real, and fairly common
> task. It should be a first class citizen in the land of Tapestry.
>
> Just to make sure the tone of this post isn't misunderstood: I love
> Tapestry. Yet, everything can stand some measure of
> improvement/rethinking.
>
> On 3/3/06, Mark Stang <ms...@pingidentity.com> wrote:
>>
>> Look at http://www.nextapp.com (a.k.a. echo2).
>>
>> regards,
>>
>> Mark
>>
>> -----Original Message-----
>> From: Apache [mailto:apache@ss78.shared.server-system.net]
>> Sent: Fri 3/3/2006 5:04 AM
>> To: tapestry-user@jakarta.apache.org
>> Subject: How to improve Tapestry
>>
>> I think Tapestry already makes a big step forward
>> but still there is a lot of things that could be made more dynamic
>> and free programmers of templates and component definitions.
>>
>> In my opinion everything could be in the database instead of
>> configuration files.
>>
>> In my idea world there should only be Java Classes
>> and no XML/Html/Page files.
>>
>> I only want to tell the system to "genrate a form with the fields
>> I tell you" and to tell it which fields are editable - the rest
>> should be done automatically. Maybe you could tell how to order or
>> align them, but I dont want to write any html templates.
>>
>>
>> -------------------- m2f --------------------
>>
>> Sent from www.TapestryForums.com
>>
>> Read this topic online here: <<topic_link>>
>>
>> http://www.tapestryforums.com/viewtopic.php?p=14479#14479
>>
>> -------------------- m2f --------------------
>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> 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: How to improve Tapestry
Posted by Mi...@expeditors.com.
Last month, I generated numerous e-mails on this list about dynamic
components. After a lot of hair pulling, because a lot of tooth pulling,
I finally figured out how to do the whole block/for/if/db solution. Yes,
this solution is pretty annoying; especially to a dev who is more
concerned about getting his product out the door than adhering to a design
dogma.
However, I think the tragic flaw is not in the difficulty of the
block/for/if solution, but in its lack of documentation. It seems to be
well understood by a few Tapestry gurus, but a complex secret to us lay
folks.
I believe that Tapestry would be best served not by rushing to fix bugs in
4.0 or forge ahead to 4.1, but by providing exhaustive documentation--the
majority of which should be examples. We spend *so much* time working
through Tapestry's unique behavior because we have very few points of
reference from which to draw. Tapestry in Action is a decent start. Kent
Tong's book is a better start (IMHO). But there needs to be more
information. More examples. We've almost completely shelved the idea of
going to 4.0 for a long time (we're coding in 3.0.3) because we believe it
needs to stabilize AND because there are fewer examples available than
3.0.3. Why fight that battle anew?
I've come to appreciate Tapestry & have found a certain amount of
efficiency to it, but only after a steep learning curve and plenty of
frustration. Two examples: dynamic components and application catalogs.
Dynamic components is possible, but there's no clear set of examples or
documentation. Application catalogs are documented, but don't work. The
workaround is *brutal*, but possible....if you're willing to go it alone.
"Todd Orr" <to...@gmail.com>
03/03/2006 08:45 AM
Please respond to
"Tapestry users" <ta...@jakarta.apache.org>
To
"Tapestry users" <ta...@jakarta.apache.org>
cc
Subject
Re: How to improve Tapestry
IMHO, the biggest feature that Tapestry is missing is solid dynamic
component generation. Time and time again you'll see devs asking the
same question in the forums, "how do I dynamically generate..." Each
time someone points out the block, the for, or the if constructs. Yet
these always seem way more difficult than they should be. Even with
these tools, content management systems are notoriously difficult to
build with Tapestry. Since Tapestry makes most things easier, this
seems to be ironic. I began using Tapestry because most of my
development time was cut in half, but the dynamic form development
tasks I had to perform were tripled in time! Now, I could be the
crappiest dev on earth, but I doubt it considering all the trouble
everyone else has with this task and Tapestry. Because Tapestry is
static, the very idea of dynamic components seems to leave a bad taste
in Howard's mouth (and the mouths of die-hard enthusiasts). Yet it
shouldn't, dynamic form generation is a very real, and fairly common
task. It should be a first class citizen in the land of Tapestry.
Just to make sure the tone of this post isn't misunderstood: I love
Tapestry. Yet, everything can stand some measure of
improvement/rethinking.
On 3/3/06, Mark Stang <ms...@pingidentity.com> wrote:
>
> Look at http://www.nextapp.com (a.k.a. echo2).
>
> regards,
>
> Mark
>
> -----Original Message-----
> From: Apache [mailto:apache@ss78.shared.server-system.net]
> Sent: Fri 3/3/2006 5:04 AM
> To: tapestry-user@jakarta.apache.org
> Subject: How to improve Tapestry
>
> I think Tapestry already makes a big step forward
> but still there is a lot of things that could be made more dynamic and
free programmers of templates and component definitions.
>
> In my opinion everything could be in the database instead of
configuration files.
>
> In my idea world there should only be Java Classes
> and no XML/Html/Page files.
>
> I only want to tell the system to "genrate a form with the fields I tell
you" and to tell it which fields are editable - the rest should be done
automatically. Maybe you could tell how to order or align them, but I dont
want to write any html templates.
>
>
> -------------------- m2f --------------------
>
> Sent from www.TapestryForums.com
>
> Read this topic online here: <<topic_link>>
>
> http://www.tapestryforums.com/viewtopic.php?p=14479#14479
>
> -------------------- m2f --------------------
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: How to improve Tapestry
Posted by Todd Orr <to...@gmail.com>.
IMHO, the biggest feature that Tapestry is missing is solid dynamic
component generation. Time and time again you'll see devs asking the
same question in the forums, "how do I dynamically generate..." Each
time someone points out the block, the for, or the if constructs. Yet
these always seem way more difficult than they should be. Even with
these tools, content management systems are notoriously difficult to
build with Tapestry. Since Tapestry makes most things easier, this
seems to be ironic. I began using Tapestry because most of my
development time was cut in half, but the dynamic form development
tasks I had to perform were tripled in time! Now, I could be the
crappiest dev on earth, but I doubt it considering all the trouble
everyone else has with this task and Tapestry. Because Tapestry is
static, the very idea of dynamic components seems to leave a bad taste
in Howard's mouth (and the mouths of die-hard enthusiasts). Yet it
shouldn't, dynamic form generation is a very real, and fairly common
task. It should be a first class citizen in the land of Tapestry.
Just to make sure the tone of this post isn't misunderstood: I love
Tapestry. Yet, everything can stand some measure of
improvement/rethinking.
On 3/3/06, Mark Stang <ms...@pingidentity.com> wrote:
>
> Look at http://www.nextapp.com (a.k.a. echo2).
>
> regards,
>
> Mark
>
> -----Original Message-----
> From: Apache [mailto:apache@ss78.shared.server-system.net]
> Sent: Fri 3/3/2006 5:04 AM
> To: tapestry-user@jakarta.apache.org
> Subject: How to improve Tapestry
>
> I think Tapestry already makes a big step forward
> but still there is a lot of things that could be made more dynamic and free programmers of templates and component definitions.
>
> In my opinion everything could be in the database instead of configuration files.
>
> In my idea world there should only be Java Classes
> and no XML/Html/Page files.
>
> I only want to tell the system to "genrate a form with the fields I tell you" and to tell it which fields are editable - the rest should be done automatically. Maybe you could tell how to order or align them, but I dont want to write any html templates.
>
>
> -------------------- m2f --------------------
>
> Sent from www.TapestryForums.com
>
> Read this topic online here: <<topic_link>>
>
> http://www.tapestryforums.com/viewtopic.php?p=14479#14479
>
> -------------------- m2f --------------------
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: How to improve Tapestry
Posted by Mark Stang <ms...@pingidentity.com>.
Look at http://www.nextapp.com (a.k.a. echo2).
regards,
Mark
-----Original Message-----
From: Apache [mailto:apache@ss78.shared.server-system.net]
Sent: Fri 3/3/2006 5:04 AM
To: tapestry-user@jakarta.apache.org
Subject: How to improve Tapestry
I think Tapestry already makes a big step forward
but still there is a lot of things that could be made more dynamic and free programmers of templates and component definitions.
In my opinion everything could be in the database instead of configuration files.
In my idea world there should only be Java Classes
and no XML/Html/Page files.
I only want to tell the system to "genrate a form with the fields I tell you" and to tell it which fields are editable - the rest should be done automatically. Maybe you could tell how to order or align them, but I dont want to write any html templates.
-------------------- m2f --------------------
Sent from www.TapestryForums.com
Read this topic online here: <<topic_link>>
http://www.tapestryforums.com/viewtopic.php?p=14479#14479
-------------------- m2f --------------------