You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Tobias Marx <su...@gmx.de> on 2008/10/01 10:38:02 UTC
My Tapestry5 suggestion list
Hi there!
Here is my list of Tapestry5 suggestions:
Tapestry5 Suggestions:
1. User .tpl instead of .tml. This way there is also no problem with syntax highlighting in most editors.
2. Make those templates compatible with SSI templates.
This is because most HTMLers will slice PSD files to SSI templates.
This way, they could directly be used in a Tapestry project
3. Make the Layout component the default component that is always used if not otherwise specified.
This saves 2 lines of code in all page templates.
4. Allow the use of templates without having to have a corresponding Java class for it.
Otherwise you to generate tons of "stupid" empty Java classes.
What do you think?
Thanks!
Toby
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: My Tapestry5 suggestion list
Posted by Daniel Jue <te...@gmail.com>.
On Wed, Oct 1, 2008 at 4:38 AM, Tobias Marx <su...@gmx.de> wrote:
> Hi there!
>
> Here is my list of Tapestry5 suggestions:
>
>
> Tapestry5 Suggestions:
>
> 1. User .tpl instead of .tml. This way there is also no problem with syntax
> highlighting in most editors.
>
We already voted a while back to change the templates from .html to .tml, so
there would be no conflicts with other file extensions, and you can
associate the editor for Tapestry templates vs static html. I think there
was another, more professional sounding reason, but that's the one that
mattered to me. It's up to you to make the file associations work in your
IDE, I see no reason to change it again unless you are Rob Smeets. ;-)
2. Make those templates compatible with SSI templates.
>
> This is because most HTMLers will slice PSD files to SSI templates.
> This way, they could directly be used in a Tapestry project
If the SSI code that is generated is valid XML, it may make it easy to wrap
with a T5 dtd and call it done. It seems that T5 goes above and beyond what
SSI can do. You would want to change all absolute or relative links to media
in the SSI code to use a T5 calculated path to the Asset (done by Injecting
the asset in the page/component class). You could make it work with the
links as is, it will just be fragile like a 1990's web page. Note that any
repeated use of the SSI (which is it's strength) is handled by making that
collection of items a component, which can then be added to any page.
If enough people use it, it may meet HLS's requirement of "Developers
First".
>
>
> 3. Make the Layout component the default component that is always used if
> not otherwise specified.
> This saves 2 lines of code in all page templates.
IMHO, It doesn't save any lines, and just makes more majic for little
benefit. The line that lists your DTD can be used to include your layout or
border, and I have multiple border type components for different sets of
pages. Having one default is just an extra caveat for newcomers.
>
>
> 4. Allow the use of templates without having to have a corresponding Java
> class for it.
> Otherwise you to generate tons of "stupid" empty Java classes.
This might be useful, say if you have a bunch of help pages or static text.
The converse is true--Java classes don't need a corresponding tml in order
to be useful. If the Loom plugin could be modified to auto create the dummy
class for you, then that would help speed things up. One caveat is that
html files don't have the naming restrictions that Java classes do. For now
I'm happy having the 1kB .class files. I usually end up injecting images or
css anyway.
>
>
>
>
> What do you think?
>
> Thanks!
>
> Toby
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: My Tapestry5 suggestion list
Posted by "Filip S. Adamsen" <fs...@fsadev.com>.
Hi,
On 2008-10-02 18:10, Alex Kotchnev wrote:
>>> 4. Allow the use of templates without having to have a corresponding
>> Java
>>> class for it.
>
> This would certainly be nice, as on a small project that I do (that for now
> only has little functionality) I already have a whole bunch of dumb java
> classes.
>
> I'll file feature requests for these in a couple of days if there are no
> objections from the list members.
I believe there's already an issue for this.
-Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: My Tapestry5 suggestion list
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 02 Oct 2008 18:04:24 -0300, Alex Kotchnev <ak...@gmail.com>
escreveu:
> Who would have thought this much discussion would come out of this :-)
Unanimities are boring and we learn next to nothing with them. :)
> I am not advocating the usage of some "other" magical framework to
> manage the layouts.
I think I have not made my point clear: I was not talking about having to
learn another framework, but learning one more feature from our framework.
> My point is this : how many applications do you have that DO
> NOT use a common layout ?
Now you raised a good discussion point. :)
But there is a hard question to answer: how can we write a layout
component that is good enough for most of the situations? What would be
its template? I don't have the answer. Maybe we could provide some
ready-to-use layouts, but I don't think this should be an intrinsic part
of the framework, just an useful add-on.
> I fail to see how having 2 artifacts (an empty class and html) is
> simpler than having just one, especially when the java class is just an
> empty class.
Simple in the sense that you have just one option (1 class - 1 template)
instead of two (1 class - 1 template, just 1 template). I'm not sure, but
I vaguely remeber Howard speaking that the obligatory page class
simplifies and gives a better performance to the inner workings of
Tapestry.
> In the little project that I do, I do have a bunch of pages that are
> composed of mostly static text, but for which I like being able to apply
> the same layout as all the other pages.
It's not exactly the same thing, but a feature request I would do is
Tapestry to pick up new classes (pages, components, mixins) and templates
after the application was started. It already picks up chages to existing
things, but not picks up new things. ;)
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
Consultor, desenvolvedor e instrutor em Java
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: My Tapestry5 suggestion list
Posted by Alex Kotchnev <ak...@gmail.com>.
Who would have thought this much discussion would come out of this :-)
Anyway, some more comments from me :
On Thu, Oct 2, 2008 at 1:51 PM, Thiago H. de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> Em Thu, 02 Oct 2008 13:10:23 -0300, Alex Kotchnev <ak...@gmail.com>
> escreveu:
>
> 5. resolving template/component class names:
>>
>> This one seems interesting, certainly some variation in the allowed naming
>> conventions seems nice if it's configurable (e.g. a naming strategy)
>>
>
> I don't know whether I agree, even if that's pluggable (something like an
> alias override). Tapestry 5 has gone in the path of defining some standards
> that must be followed and I think of it as a plus. I really love the 1:1:1
> URL-page-template relationship in Tapestry 5. It makes it very simple and
> straightforward to find anything related to a page.
I would think (having seen the other small interfaces that are in T5)
that there already is a service that performs some of this (e.g. the part
that shortens the URLs) strategy of mapping class names to page names to
URLs. Thus, it might be just an issue of documenting what needs to be
overriden and implemented if I wanted to have the FooBar.class map to
foo-bar.html instead of FooBar.html
>
> > 3. Make the Layout component the default component that is always used
>>> if
>>> > not otherwise specified.
>>> > This saves 2 lines of code in all page templates.
>>>
>>
>> A step further : it would be nice if a page could specify either in the
>> template or in the java class which border component to use. Grails for
>> example uses Sitemesh layouts, and each rendered page (gsp) can specify
>> the layout to use .
>>
>
> I disagree.
>
> You can accomplish the same using a Layout component with n t:blocks, one
> for each "theme". This Layout would have a non-required parameter specifying
> what theme to use.
>
> I really like the idea that templating (in the Layout component sense) in
> Tapestry 5 is made through an ordinary component, no through some one more
> special mechanism that must be learned.
I am not advocating the usage of some "other" magical framework to manage
the layouts. My point is this : how many applications do you have that DO
NOT use a common layout ? To take it even further, how many application did
you create where creating the layout component (even a basic one) was not
one of the first thing you did in the prototype ? I think that the fact that
I often start w/ some kind of layout, and in the end *always* end up using a
layout, makes it very hard to explain why T5 doesn't have a layout component
in the framework core (instead of letting it sit on the wiki).
Daniel Jue mentions that having a default layout would be an extra caveat
for newcomers and I have to disagree with that very strongly : I think that
not having some kind of layout support is an extra (and unnecessary) hurdle
that a newcomer has to clear, and instead of being an extra caveat providing
a default layout implementation would be a sensible default (yeah, all that,
opinionated software, convention over configuration, etc)
I do agree with the statement that it is nice that the layout in Tapestry is
just another component, and there is no "other" magical framework to learn
(although if there was, considering how much magic already happens in T5,
one more spell wouldn't break the camel's back). It seems like the Layout
component on the wiki that can set the title on the page, a map of key/value
pairs that the client page can set for the usage by the layout, and the
ability contribute some blocks from the page to the outside layout would be
very valuable.
Now, whenever you have to create a complex layout (like the one you
described, with a bunch of themes and such), then you'll definitely have to
create your own, but at least it wouldn't be the first thing you have to do
when you start working w/ T5 . People often talk about the steep learning
curve w/ Tapestry, and I feel that this is one of the things that
contributes to it.
>
> > 4. Allow the use of templates without having to have a corresponding
>>> Java
>>> > class for it.
>>>
>>
>> This would certainly be nice, as on a small project that I do (that for
>> now only has little functionality) I already have a whole bunch of dumb java
>> classes.
>>
>
> Tapestry 4 (and maybe previous versions too, but I haven't used them) were
> exactly like you're asking, but Howard dropped them in Tapestry 5 in order
> to simplify things, not having two different paths to reach the same goal.
> Of course, he can speak way better to me why he had done that. :)
I fail to see how having 2 artifacts (an empty class and html) is simpler
than having just one, especially when the java class is just an empty class.
In the little project that I do, I do have a bunch of pages that are
composed of mostly static text, but for which I like being able to apply the
same layout as all the other pages.
Cheers,
Alex Kotchnev
Re: My Tapestry5 suggestion list
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 02 Oct 2008 13:10:23 -0300, Alex Kotchnev <ak...@gmail.com>
escreveu:
> 5. resolving template/component class names:
>
> This one seems interesting, certainly some variation in the allowed
> naming
> conventions seems nice if it's configurable (e.g. a naming strategy)
I don't know whether I agree, even if that's pluggable (something like an
alias override). Tapestry 5 has gone in the path of defining some
standards that must be followed and I think of it as a plus. I really love
the 1:1:1 URL-page-template relationship in Tapestry 5. It makes it very
simple and straightforward to find anything related to a page.
>> > 1. User .tpl instead of .tml. This way there is also no problem with
>> > syntax highlighting in most editors.
>>
>
> This one seems quite arbitrary, .tml seems just as tood as .tpl, which
> "most editors" are you talking about ?
I see no reason for changes.
>> > 3. Make the Layout component the default component that is always
>> used if
>> > not otherwise specified.
>> > This saves 2 lines of code in all page templates.
>
> A step further : it would be nice if a page could specify either in the
> template or in the java class which border component to use. Grails for
> example uses Sitemesh layouts, and each rendered page (gsp) can specify
> the layout to use .
I disagree.
You can accomplish the same using a Layout component with n t:blocks, one
for each "theme". This Layout would have a non-required parameter
specifying what theme to use.
I really like the idea that templating (in the Layout component sense) in
Tapestry 5 is made through an ordinary component, no through some one more
special mechanism that must be learned.
>> > 4. Allow the use of templates without having to have a corresponding
>> Java
>> > class for it.
>
> This would certainly be nice, as on a small project that I do (that for
> now only has little functionality) I already have a whole bunch of dumb
> java
> classes.
Tapestry 4 (and maybe previous versions too, but I haven't used them) were
exactly like you're asking, but Howard dropped them in Tapestry 5 in order
to simplify things, not having two different paths to reach the same goal.
Of course, he can speak way better to me why he had done that. :)
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
Consultor, desenvolvedor e instrutor em Java
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: My Tapestry5 suggestion list
Posted by Alex Kotchnev <ak...@gmail.com>.
5. resolving template/component class names:
This one seems interesting, certainly some variation in the allowed naming
conventions seems nice if it's configurable (e.g. a naming strategy)
>
> > 1. User .tpl instead of .tml. This way there is also no problem with
> > syntax highlighting in most editors.
>
This one seems quite arbitrary, .tml seems just as tood as .tpl, which
"most editors" are you talking about ?
> > 2. Make those templates compatible with SSI templates.
> >
> > This is because most HTMLers will slice PSD files to SSI templates.
> > This way, they could directly be used in a Tapestry project
> >
>
Can you give an example of how a template might be "compatible" with an
SSI template ?
>
> > 3. Make the Layout component the default component that is always used if
> > not otherwise specified.
> > This saves 2 lines of code in all page templates.
>
A step further : it would be nice if a page could specify either in the
template or in the java class which border component to use. Grails for
example uses Sitemesh layouts, and each rendered page (gsp) can specify the
layout to use .
>
> >
> > 4. Allow the use of templates without having to have a corresponding
> Java
> > class for it.
>
This would certainly be nice, as on a small project that I do (that for now
only has little functionality) I already have a whole bunch of dumb java
classes.
I'll file feature requests for these in a couple of days if there are no
objections from the list members.
Cheers,
Alex Kotchnev
Re: My Tapestry5 suggestion list
Posted by Tobias Marx <su...@gmx.de>.
5. resolving template/component class names:
Also allow SomeExample for a component class name if the template is called some-example.
-------- Original-Nachricht --------
> Datum: Wed, 01 Oct 2008 10:38:02 +0200
> Von: "Tobias Marx" <su...@gmx.de>
> An: "Tapestry users" <us...@tapestry.apache.org>
> Betreff: My Tapestry5 suggestion list
> Hi there!
>
> Here is my list of Tapestry5 suggestions:
>
>
> Tapestry5 Suggestions:
>
> 1. User .tpl instead of .tml. This way there is also no problem with
> syntax highlighting in most editors.
>
>
> 2. Make those templates compatible with SSI templates.
>
> This is because most HTMLers will slice PSD files to SSI templates.
> This way, they could directly be used in a Tapestry project
>
> 3. Make the Layout component the default component that is always used if
> not otherwise specified.
> This saves 2 lines of code in all page templates.
>
> 4. Allow the use of templates without having to have a corresponding Java
> class for it.
>
> Otherwise you to generate tons of "stupid" empty Java classes.
>
>
>
> What do you think?
>
> Thanks!
>
> Toby
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: My Tapestry5 suggestion list
Posted by Chris Lewis <ch...@bellsouth.net>.
Good point.
Markus Joschko wrote:
> Talking about configurable URLs: Don't forget i18n issues.
> We once had a product where customers wanted to have the URL
> internationalized to be meaningful in different countries.
> This requirement is not uncommon in Europa at least.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
http://thegodcode.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: My Tapestry5 suggestion list
Posted by Markus Joschko <ma...@gmail.com>.
Talking about configurable URLs: Don't forget i18n issues.
We once had a product where customers wanted to have the URL
internationalized to be meaningful in different countries.
This requirement is not uncommon in Europa at least.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: My Tapestry5 suggestion list
Posted by Marcelo Lotif <ml...@gmail.com>.
Hi all,I think that Chris' points are the most important ones, together with
the #5 from Tobias (resolving template/component class names, i.e. naming
strategy). Mainly the configurable URL's, the built in feature is REALLY
great, but it's tricky sometimes...
Adding these features to the core will make me feel real happy :)
On Thu, Oct 2, 2008 at 7:29 PM, Chris Lewis <ch...@bellsouth.net>wrote:
> Hello,
>
> The only one of these that I'm interested in is the ability to have
> class-less components (just markup, no logic). I filed an issue for this
> many months ago, and am no longer certain where in the mix it is. I'll
> add one:
>
> Configurable URL-mapping service.
>
> I loathe - /loathe/ the fact that I have no control over the URL
> structure, and that it directly reflects the page class structure of the
> applications. There are simply cases where I want to have some kind of
> routing/rewriting feature, not to mention that management will at times
> demand control over such a thing.
>
> Tobias Marx wrote:
> > Hi there!
> >
> > Here is my list of Tapestry5 suggestions:
> >
> >
> > Tapestry5 Suggestions:
> >
> > 1. User .tpl instead of .tml. This way there is also no problem with
> syntax highlighting in most editors.
> >
> >
> > 2. Make those templates compatible with SSI templates.
> >
> > This is because most HTMLers will slice PSD files to SSI templates.
> > This way, they could directly be used in a Tapestry project
> >
> > 3. Make the Layout component the default component that is always used if
> not otherwise specified.
> > This saves 2 lines of code in all page templates.
> >
> > 4. Allow the use of templates without having to have a corresponding
> Java class for it.
> >
> > Otherwise you to generate tons of "stupid" empty Java classes.
> >
> >
> >
> > What do you think?
> >
> > Thanks!
> >
> > Toby
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
> >
>
> --
> http://thegodcode.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Atenciosamente,
Marcelo Lotif
Programador Java e Tapestry
FIEC - Federação das Indústrias do Estado do Ceará
(85) 3477-5910
Re: My Tapestry5 suggestion list
Posted by Chris Lewis <ch...@bellsouth.net>.
Hello,
The only one of these that I'm interested in is the ability to have
class-less components (just markup, no logic). I filed an issue for this
many months ago, and am no longer certain where in the mix it is. I'll
add one:
Configurable URL-mapping service.
I loathe - /loathe/ the fact that I have no control over the URL
structure, and that it directly reflects the page class structure of the
applications. There are simply cases where I want to have some kind of
routing/rewriting feature, not to mention that management will at times
demand control over such a thing.
Tobias Marx wrote:
> Hi there!
>
> Here is my list of Tapestry5 suggestions:
>
>
> Tapestry5 Suggestions:
>
> 1. User .tpl instead of .tml. This way there is also no problem with syntax highlighting in most editors.
>
>
> 2. Make those templates compatible with SSI templates.
>
> This is because most HTMLers will slice PSD files to SSI templates.
> This way, they could directly be used in a Tapestry project
>
> 3. Make the Layout component the default component that is always used if not otherwise specified.
> This saves 2 lines of code in all page templates.
>
> 4. Allow the use of templates without having to have a corresponding Java class for it.
>
> Otherwise you to generate tons of "stupid" empty Java classes.
>
>
>
> What do you think?
>
> Thanks!
>
> Toby
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
http://thegodcode.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org