You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Francois Armand <fa...@linagora.com> on 2008/10/10 10:56:26 UTC
[T5] What is your missing feature / bloking bug before 5.0 ?
Ok, so we reach the point where T5.0 final is imminent, and we are all
(I think) really happy of that.
As we also want that T5 really makes its way in the Java Web ecosystem,
I think it always miss some really little things that are really
important for a .0 release.
I purpose to start this discussion in the ml, and when some major gap
emerge, to post them in the issue tracker, and vote for them.
So, for me, what I expect for 5.0 :
1/ - full and complete and rather simple internationalization : I really
believe that a web framework can ignore other language and culture
(date, number) today ;
that include validator translation and stuff like that.
2/ - valid XHTML, even for IE, by default. The workaround is here for
some time, but why it's not default ? See
http://wiki.apache.org/tapestry/Tapestry5HowToXhtml
3/ - something around AJAX documentation and Zone update inside a form
(that includes update of part of a form on change from a select :
https://issues.apache.org/jira/browse/TAP5-138)
4/- a property symbol provider, also simple and in use almost always
@see
http://wiki.apache.org/tapestry/Tapestry5HowToReadSymbolsFromPropertiesFile
Without 1, T5 just can't get is path easely outside English contries ;
Without 2, T5 can hardly be considered top-level (even if on the
technical point of vue, it's completly rigth and it's IE fault), without
3, AJAX seems not so well integrated, and it's hot stuff todays, and 4
is so much common in a application, why do we have to bother with that
each time ?
Other simple stuff that should be corrected before 5.0 (in my opinion) :
- why hidden field is still missing ? It's so easy to add, a new user
should not even have to search for that !
- https://issues.apache.org/jira/browse/TAP5-257, that seems to bring
other pb with decorator and the like ;
What do you thing about that ? Does it make sense to open a "community
want that" bug, that have to be quick to handle, but that brings the
attention of T5 developers on what we need ? Perhaps we can already vote
for existing bugs ? Which ones ?
--
Francois Armand
Etudes & Développements J2EE
Groupe Linagora - http://www.linagora.com
Tél.: +33 (0)1 58 18 68 28
-----------
InterLDAP - http://interldap.org
FederID - http://www.federid.org/
Open Source identities management and federation
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] What is your missing feature / bloking bug before 5.0 ?
Posted by Neeme Praks <ne...@apache.org>.
I agree with all the points.
And, for point #4, there is also a JIRA issue you can vote on:
https://issues.apache.org/jira/browse/TAP5-223
As it is a simple addition and commonly used, I do not see why it should
not be included in 5.0. Then the wiki page can just describe how to
enable it (actually, it would make sense to add a note about that topic
to "official" T5 documentation also).
Rgds,
Neeme
Francois Armand wrote:
> Ok, so we reach the point where T5.0 final is imminent, and we are all
> (I think) really happy of that.
> As we also want that T5 really makes its way in the Java Web ecosystem,
> I think it always miss some really little things that are really
> important for a .0 release.
>
> I purpose to start this discussion in the ml, and when some major gap
> emerge, to post them in the issue tracker, and vote for them.
>
> So, for me, what I expect for 5.0 :
> 1/ - full and complete and rather simple internationalization : I really
> believe that a web framework can ignore other language and culture
> (date, number) today ;
> that include validator translation and stuff like that.
> 2/ - valid XHTML, even for IE, by default. The workaround is here for
> some time, but why it's not default ? See
> http://wiki.apache.org/tapestry/Tapestry5HowToXhtml
> 3/ - something around AJAX documentation and Zone update inside a form
> (that includes update of part of a form on change from a select :
> https://issues.apache.org/jira/browse/TAP5-138)
> 4/- a property symbol provider, also simple and in use almost always
> @see
> http://wiki.apache.org/tapestry/Tapestry5HowToReadSymbolsFromPropertiesFile
>
> Without 1, T5 just can't get is path easely outside English contries ;
> Without 2, T5 can hardly be considered top-level (even if on the
> technical point of vue, it's completly rigth and it's IE fault), without
> 3, AJAX seems not so well integrated, and it's hot stuff todays, and 4
> is so much common in a application, why do we have to bother with that
> each time ?
>
> Other simple stuff that should be corrected before 5.0 (in my opinion) :
> - why hidden field is still missing ? It's so easy to add, a new user
> should not even have to search for that !
> - https://issues.apache.org/jira/browse/TAP5-257, that seems to bring
> other pb with decorator and the like ;
>
> What do you thing about that ? Does it make sense to open a "community
> want that" bug, that have to be quick to handle, but that brings the
> attention of T5 developers on what we need ? Perhaps we can already vote
> for existing bugs ? Which ones ?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] What is your missing feature / bloking bug before 5.0 ?
Posted by Onno Scheffers <on...@piraya.nl>.
Great sum up.
There has been talk in the past about the missing $remove$, $body$ etc.
which we had in Tapestry 4 if I'm not mistaken.
There are work-arounds in T5, but I would expect those to be available in a
release candidate of T5.
regards,
Onno Scheffers
On Mon, Oct 13, 2008 at 11:36 AM, Francois Armand <fa...@linagora.com>wrote:
> OK, so a little sum up with the matching bug reference, so that at least
> everybody can vote for this easaly. It would be quite simple afterward to
> bring the T5 dev attention to bugs with tens of vote for them.
>
> Note: some bugs are in the Tapestry project, not the TAP5 one. I thing
> there owners should reopen them in the new TAP5 project.
>
> So ! Go and vote for your bugs and features !!
>
> (notice 2 : I really believe that T5 is a WONDERFUL framework, and it's
> just that the 5.0 is so much important in people (I mean, non tech) spirit
> that it deserve to reflect the beauty of T5. I would be a mass that people
> stop after only some trying ours because they it one of the these bugs).
>
>> So, for me, what I expect for 5.0 :
>> 1/ - full and complete and rather simple internationalization : I really
>> believe that a web framework can ignore other language and culture (date,
>> number) today ;
>> that include validator translation and stuff like that.
>>
> It's a point that seems to drove a lot of attention, and which is really
> important for the success of T5 outside English-speaking countries.
> So, there is the validator already opened bug :
> https://issues.apache.org/jira/browse/TAP5-211
>
> UTF-8 in autocomplete, with the one-line patch :
> https://issues.apache.org/jira/browse/TAPESTRY-2433
>
> "There is no data to display." is hardcoded in Grid.tml :
> https://issues.apache.org/jira/browse/TAP5-262
>
> If other specific issue with i18n appears, please open other bugs and
> linked them here.
>
> 2/ - valid XHTML, even for IE, by default. The workaround is here for some
>> time, but why it's not default ? See
>> http://wiki.apache.org/tapestry/Tapestry5HowToXhtml
>>
> It appears that it's important that things will "just work" on IE, even if
> this browser suck. Perhaps a configuration value ?
> So, the bug :
> https://issues.apache.org/jira/browse/TAP5-263
>
>
> Others queries was raised :
>
> * Javascript at top or bottom of the page, what seems to be a really hot
> topic, and does not required a lot of modification in T5 code base :
> https://issues.apache.org/jira/browse/TAPESTRY-2364
>
> The bug is closed, so perhaps it will be good to open a new one for 5.0.16
> and post the link ?
>
> * ApplicationStateObject, "mileading name". The fact here is that after 5.0
> released, the named will be write in the stone forever. Personnaly, I have
> no opinion on that topic, but it appears that several members in my team
> don't feel at ease with this name.
> Related bug :
> https://issues.apache.org/jira/browse/TAPESTRY-2703
>
> * T5 lacks queries with named parameters, especially for search and this
> kind of queries.
> I'm fear that this one may require a lot of modification in the T5 code
> base. Some solution are purposed, like having a map in the query :
>
> http://foo/myT5app/mypage/normalcontext/mycontextmap=[key1:value1,key2:value2]/othercontextparam
> will match a onActivate(String normalcontext, Map<String,String>
> mycontextmap, String othercontextparam).
> The map would contains the different key/values.
> The bug is here :
> https://issues.apache.org/jira/browse/TAP5-264
>
> * Missing "hidden" field component : a rather simple thing to do, and a
> strange missing :
> https://issues.apache.org/jira/browse/TAP5-265
>
> The next queries seems to be less important, so for now I didn't opened
> other bugs.
>
>> 3/ - something around AJAX documentation and Zone update inside a form
>> (that includes update of part of a form on change from a select :
>> https://issues.apache.org/jira/browse/TAP5-138)
>> 4/- a property symbol provider, also simple and in use almost always @see
>> http://wiki.apache.org/tapestry/Tapestry5HowToReadSymbolsFromPropertiesFile
>> [...]
>> Other simple stuff that should be corrected before 5.0 (in my opinion) :
>> - why hidden field is still missing ? It's so easy to add, a new user
>> should not even have to search for that !
>> - https://issues.apache.org/jira/browse/TAP5-257, that seems to bring
>> other pb with decorator and the like ;
>>
> Enloy !
>
>
> --
> Francois Armand
> Etudes & Développements J2EE
> Groupe Linagora - http://www.linagora.com
> Tél.: +33 (0)1 58 18 68 28
> -----------
> InterLDAP - http://interldap.org FederID - http://www.federid.org/
> Open Source identities management and federation
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: [T5] What is your missing feature / bloking bug before 5.0 ?
Posted by Francois Armand <fa...@linagora.com>.
OK, so a little sum up with the matching bug reference, so that at least
everybody can vote for this easaly. It would be quite simple afterward
to bring the T5 dev attention to bugs with tens of vote for them.
Note: some bugs are in the Tapestry project, not the TAP5 one. I thing
there owners should reopen them in the new TAP5 project.
So ! Go and vote for your bugs and features !!
(notice 2 : I really believe that T5 is a WONDERFUL framework, and it's
just that the 5.0 is so much important in people (I mean, non tech)
spirit that it deserve to reflect the beauty of T5. I would be a mass
that people stop after only some trying ours because they it one of the
these bugs).
> So, for me, what I expect for 5.0 :
> 1/ - full and complete and rather simple internationalization : I
> really believe that a web framework can ignore other language and
> culture (date, number) today ;
> that include validator translation and stuff like that.
It's a point that seems to drove a lot of attention, and which is really
important for the success of T5 outside English-speaking countries.
So, there is the validator already opened bug :
https://issues.apache.org/jira/browse/TAP5-211
UTF-8 in autocomplete, with the one-line patch :
https://issues.apache.org/jira/browse/TAPESTRY-2433
"There is no data to display." is hardcoded in Grid.tml :
https://issues.apache.org/jira/browse/TAP5-262
If other specific issue with i18n appears, please open other bugs and
linked them here.
> 2/ - valid XHTML, even for IE, by default. The workaround is here for
> some time, but why it's not default ? See
> http://wiki.apache.org/tapestry/Tapestry5HowToXhtml
It appears that it's important that things will "just work" on IE, even
if this browser suck. Perhaps a configuration value ?
So, the bug :
https://issues.apache.org/jira/browse/TAP5-263
Others queries was raised :
* Javascript at top or bottom of the page, what seems to be a really hot
topic, and does not required a lot of modification in T5 code base :
https://issues.apache.org/jira/browse/TAPESTRY-2364
The bug is closed, so perhaps it will be good to open a new one for
5.0.16 and post the link ?
* ApplicationStateObject, "mileading name". The fact here is that after
5.0 released, the named will be write in the stone forever. Personnaly,
I have no opinion on that topic, but it appears that several members in
my team don't feel at ease with this name.
Related bug :
https://issues.apache.org/jira/browse/TAPESTRY-2703
* T5 lacks queries with named parameters, especially for search and this
kind of queries.
I'm fear that this one may require a lot of modification in the T5 code
base. Some solution are purposed, like having a map in the query :
http://foo/myT5app/mypage/normalcontext/mycontextmap=[key1:value1,key2:value2]/othercontextparam
will match a onActivate(String normalcontext, Map<String,String>
mycontextmap, String othercontextparam).
The map would contains the different key/values.
The bug is here :
https://issues.apache.org/jira/browse/TAP5-264
* Missing "hidden" field component : a rather simple thing to do, and a
strange missing :
https://issues.apache.org/jira/browse/TAP5-265
The next queries seems to be less important, so for now I didn't opened
other bugs.
> 3/ - something around AJAX documentation and Zone update inside a form
> (that includes update of part of a form on change from a select :
> https://issues.apache.org/jira/browse/TAP5-138)
> 4/- a property symbol provider, also simple and in use almost always
> @see
> http://wiki.apache.org/tapestry/Tapestry5HowToReadSymbolsFromPropertiesFile
>
> [...]
> Other simple stuff that should be corrected before 5.0 (in my opinion) :
> - why hidden field is still missing ? It's so easy to add, a new user
> should not even have to search for that !
> - https://issues.apache.org/jira/browse/TAP5-257, that seems to bring
> other pb with decorator and the like ;
Enloy !
--
Francois Armand
Etudes & Développements J2EE
Groupe Linagora - http://www.linagora.com
Tél.: +33 (0)1 58 18 68 28
-----------
InterLDAP - http://interldap.org
FederID - http://www.federid.org/
Open Source identities management and federation
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] What is your missing feature / bloking bug before 5.0 ?
Posted by Geoff Callender <ge...@gmail.com>.
An umbrella JIRA issue will turn into a mess unless it spells out a
clear procedure. I think it should state a procedure in its opening
lines.
A procedure that might work:
(1) Francis will manage the list of issues - only he may add or remove
items from the list, and he will do so in response to discussion on
the mailing list. Francis, would this be OK with you?
(2) Only Tapestry developers will add their comments and opinions on
why each issue will, or will not, be addressed in 5.0.
(3) The suggestions in the mailing list must be easy to spot, so the
subject line of each each new suggestion should start with the same
agreed prefix - perhaps "[5.0 essential]" or "[5.0 dealbreaker]" or
perhaps the umbrella issue's id, eg. "[TAP5-1234]".
On 11/10/2008, at 1:56 PM, Geoff Callender wrote:
> I like the idea of opening an umbrella issue for "user requests for
> 5.0 release". Howard and crew will be able to record their decisions
> on why each item will get in or be deferred.
>
> I completely agree with your first 5 choices. The 6th one
> (TAP5-257) I do not have an opinion on.
>
> I would add one more -
> "ApplicationStateObject is a misleading term" https://issues.apache.org/jira/browse/TAPESTRY-2703
> because once 5.0 is released it will be too late to change. The
> concept will be baked in.
>
> On 10/10/2008, at 7:56 PM, Francois Armand wrote:
>
>> Ok, so we reach the point where T5.0 final is imminent, and we are
>> all (I think) really happy of that.
>> As we also want that T5 really makes its way in the Java Web
>> ecosystem, I think it always miss some really little things that
>> are really important for a .0 release.
>>
>> I purpose to start this discussion in the ml, and when some major
>> gap emerge, to post them in the issue tracker, and vote for them.
>>
>> So, for me, what I expect for 5.0 :
>> 1/ - full and complete and rather simple internationalization : I
>> really believe that a web framework can ignore other language and
>> culture (date, number) today ;
>> that include validator translation and stuff like that.
>> 2/ - valid XHTML, even for IE, by default. The workaround is here
>> for some time, but why it's not default ? See http://wiki.apache.org/tapestry/Tapestry5HowToXhtml
>> 3/ - something around AJAX documentation and Zone update inside a
>> form (that includes update of part of a form on change from a
>> select : https://issues.apache.org/jira/browse/TAP5-138)
>> 4/- a property symbol provider, also simple and in use almost
>> always @see http://wiki.apache.org/tapestry/Tapestry5HowToReadSymbolsFromPropertiesFile
>>
>> Without 1, T5 just can't get is path easely outside English
>> contries ; Without 2, T5 can hardly be considered top-level (even
>> if on the technical point of vue, it's completly rigth and it's IE
>> fault), without 3, AJAX seems not so well integrated, and it's hot
>> stuff todays, and 4 is so much common in a application, why do we
>> have to bother with that each time ?
>>
>> Other simple stuff that should be corrected before 5.0 (in my
>> opinion) :
>> - why hidden field is still missing ? It's so easy to add, a new
>> user should not even have to search for that !
>> - https://issues.apache.org/jira/browse/TAP5-257, that seems to
>> bring other pb with decorator and the like ;
>>
>> What do you thing about that ? Does it make sense to open a
>> "community want that" bug, that have to be quick to handle, but
>> that brings the attention of T5 developers on what we need ?
>> Perhaps we can already vote for existing bugs ? Which ones ?
>>
>> --
>> Francois Armand
>> Etudes & Développements J2EE
>> Groupe Linagora - http://www.linagora.com
>> Tél.: +33 (0)1 58 18 68 28
>> -----------
>> InterLDAP - http://interldap.org FederID - http://www.federid.org/
>> Open Source identities management and federation
>>
>>
>> ---------------------------------------------------------------------
>> 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: [T5] What is your missing feature / bloking bug before 5.0 ?
Posted by Geoff Callender <ge...@gmail.com>.
I like the idea of opening an umbrella issue for "user requests for
5.0 release". Howard and crew will be able to record their decisions
on why each item will get in or be deferred.
I completely agree with your first 5 choices. The 6th one (TAP5-257)
I do not have an opinion on.
I would add one more -
"ApplicationStateObject is a misleading term" https://issues.apache.org/jira/browse/TAPESTRY-2703
because once 5.0 is released it will be too late to change. The
concept will be baked in.
On 10/10/2008, at 7:56 PM, Francois Armand wrote:
> Ok, so we reach the point where T5.0 final is imminent, and we are
> all (I think) really happy of that.
> As we also want that T5 really makes its way in the Java Web
> ecosystem, I think it always miss some really little things that are
> really important for a .0 release.
>
> I purpose to start this discussion in the ml, and when some major
> gap emerge, to post them in the issue tracker, and vote for them.
>
> So, for me, what I expect for 5.0 :
> 1/ - full and complete and rather simple internationalization : I
> really believe that a web framework can ignore other language and
> culture (date, number) today ;
> that include validator translation and stuff like that.
> 2/ - valid XHTML, even for IE, by default. The workaround is here
> for some time, but why it's not default ? See http://wiki.apache.org/tapestry/Tapestry5HowToXhtml
> 3/ - something around AJAX documentation and Zone update inside a
> form (that includes update of part of a form on change from a
> select : https://issues.apache.org/jira/browse/TAP5-138)
> 4/- a property symbol provider, also simple and in use almost always
> @see http://wiki.apache.org/tapestry/Tapestry5HowToReadSymbolsFromPropertiesFile
>
> Without 1, T5 just can't get is path easely outside English
> contries ; Without 2, T5 can hardly be considered top-level (even if
> on the technical point of vue, it's completly rigth and it's IE
> fault), without 3, AJAX seems not so well integrated, and it's hot
> stuff todays, and 4 is so much common in a application, why do we
> have to bother with that each time ?
>
> Other simple stuff that should be corrected before 5.0 (in my
> opinion) :
> - why hidden field is still missing ? It's so easy to add, a new
> user should not even have to search for that !
> - https://issues.apache.org/jira/browse/TAP5-257, that seems to
> bring other pb with decorator and the like ;
>
> What do you thing about that ? Does it make sense to open a
> "community want that" bug, that have to be quick to handle, but that
> brings the attention of T5 developers on what we need ? Perhaps we
> can already vote for existing bugs ? Which ones ?
>
> --
> Francois Armand
> Etudes & Développements J2EE
> Groupe Linagora - http://www.linagora.com
> Tél.: +33 (0)1 58 18 68 28
> -----------
> InterLDAP - http://interldap.org FederID - http://www.federid.org/
> Open Source identities management and federation
>
>
> ---------------------------------------------------------------------
> 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: [T5] What is your missing feature / bloking bug before 5.0 ?
Posted by Onno Scheffers <on...@piraya.nl>.
Hi Francois,
I agree with your suggestions.
I would like to be able to configure Javascript to be included in the head
section rather than at the bottom of the page. We recently had a discussion
about it here: https://issues.apache.org/jira/browse/TAPESTRY-2364.
Without it you need hacks to execute Javascript before the page is rendered,
which is really a common thing to do, especially if you setup your page to
also work without Javascript.
regards,
Onno
On Fri, Oct 10, 2008 at 10:56 AM, Francois Armand <fa...@linagora.com>wrote:
> Ok, so we reach the point where T5.0 final is imminent, and we are all (I
> think) really happy of that.
> As we also want that T5 really makes its way in the Java Web ecosystem, I
> think it always miss some really little things that are really important for
> a .0 release.
>
> I purpose to start this discussion in the ml, and when some major gap
> emerge, to post them in the issue tracker, and vote for them.
>
> So, for me, what I expect for 5.0 :
> 1/ - full and complete and rather simple internationalization : I really
> believe that a web framework can ignore other language and culture (date,
> number) today ;
> that include validator translation and stuff like that.
> 2/ - valid XHTML, even for IE, by default. The workaround is here for some
> time, but why it's not default ? See
> http://wiki.apache.org/tapestry/Tapestry5HowToXhtml
> 3/ - something around AJAX documentation and Zone update inside a form
> (that includes update of part of a form on change from a select :
> https://issues.apache.org/jira/browse/TAP5-138)
> 4/- a property symbol provider, also simple and in use almost always @see
> http://wiki.apache.org/tapestry/Tapestry5HowToReadSymbolsFromPropertiesFile
>
> Without 1, T5 just can't get is path easely outside English contries ;
> Without 2, T5 can hardly be considered top-level (even if on the technical
> point of vue, it's completly rigth and it's IE fault), without 3, AJAX seems
> not so well integrated, and it's hot stuff todays, and 4 is so much common
> in a application, why do we have to bother with that each time ?
>
> Other simple stuff that should be corrected before 5.0 (in my opinion) :
> - why hidden field is still missing ? It's so easy to add, a new user
> should not even have to search for that !
> - https://issues.apache.org/jira/browse/TAP5-257, that seems to bring
> other pb with decorator and the like ;
>
> What do you thing about that ? Does it make sense to open a "community want
> that" bug, that have to be quick to handle, but that brings the attention of
> T5 developers on what we need ? Perhaps we can already vote for existing
> bugs ? Which ones ?
>
> --
> Francois Armand
> Etudes & Développements J2EE
> Groupe Linagora - http://www.linagora.com
> Tél.: +33 (0)1 58 18 68 28
> -----------
> InterLDAP - http://interldap.org FederID - http://www.federid.org/
> Open Source identities management and federation
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: [T5] What is your missing feature / bloking bug before 5.0 ?
Posted by Joel Halbert <jo...@su3analytics.com>.
(other than that I did want to make clear I think it's a great framework!)
Joel Halbert wrote:
> I was wondering whether anyone missed the lack of direct support for
> named context parameters?
> I try to keep my pages as stateless as possible (thus bookmarkable)
> and better support for "named" context variables would make this much
> easier.
>
> José Paumard wrote:
>> François,
>>
>> I think we all agree that T5 is an outstanding framework on many
>> points. I've been using it for nearly a year now, with great pleasure
>> and satisfactions.
>>
>> May I add those two issues :
>> https://issues.apache.org/jira/browse/TAPESTRY-2433
>> I reported this bug quite some time ago, Howard closed it when v0.15
>> got UTF8, but in fact it's still here.
>>
>> And another one
>> (https://issues.apache.org/jira/browse/TAPESTRY-2432), that really
>> hinders the concept of customized property editor. This concept is
>> very powerful : build your own property editor, put your beans in a
>> bean editor, and everything works flawlessly (and it does !). But
>> when your property spans over more than one basic component (and
>> which one doesnt ? if is was a simple property, why would you be
>> writing an editor for it ?), you cant have some of your code executed
>> between the injection of the form values in your editor, and the
>> reading of the edited property by T5 (T5 doesnt use the getter /
>> setter stuff to read / write those properties). So you have no way to
>> cleanly build your property object from the values in the HTML form.
>>
>> And the third one (remember the spanish inquisition ? ;))
>>
>> Please, ho please, remove that hard coded "There is no data to
>> display." from Grid.tml !
>>
>> Thank you,
>>
>> José
>>
>> Ulrich Stärk a écrit :
>>> Am Fr, 10.10.2008, 10:56, schrieb Francois Armand:
>>>
>>>> Ok, so we reach the point where T5.0 final is imminent, and we are all
>>>> (I think) really happy of that.
>>>> As we also want that T5 really makes its way in the Java Web
>>>> ecosystem,
>>>> I think it always miss some really little things that are really
>>>> important for a .0 release.
>>>>
>>>> I purpose to start this discussion in the ml, and when some major gap
>>>> emerge, to post them in the issue tracker, and vote for them.
>>>>
>>>> So, for me, what I expect for 5.0 :
>>>> 1/ - full and complete and rather simple internationalization : I
>>>> really
>>>> believe that a web framework can ignore other language and culture
>>>> (date, number) today ;
>>>> that include validator translation and stuff like that.
>>>>
>>>
>>> I believe you meant "can't" ;-)
>>>
>>> https://issues.apache.org/jira/browse/TAP5-211
>>>
>>> This is the thing I care the most about as there is no workaround
>>> without
>>> breaking other things.
>>>
>>>
>>>
>>>> 2/ - valid XHTML, even for IE, by default. The workaround is here for
>>>> some time, but why it's not default ? See
>>>> http://wiki.apache.org/tapestry/Tapestry5HowToXhtml
>>>> 3/ - something around AJAX documentation and Zone update inside a form
>>>> (that includes update of part of a form on change from a select :
>>>> https://issues.apache.org/jira/browse/TAP5-138)
>>>>
>>>
>>> That seems to be a very frequent use case and should really be
>>> implemented
>>> soon.
>>>
>>>
>>>> 4/- a property symbol provider, also simple and in use almost always
>>>> @see
>>>> http://wiki.apache.org/tapestry/Tapestry5HowToReadSymbolsFromPropertiesFile
>>>>
>>>>
>>>
>>> I think this is not that important to have. There is a simple
>>> solution in
>>> the wiki that people can refactor into a module, put it in a jar
>>> file and
>>> drop it into their projects as needed. On the other hand this
>>> wouldn't be
>>> too complicated to integrate into the core distribution, given that the
>>> code already exists.
>>>
>>>
>>>> Without 1, T5 just can't get is path easely outside English contries ;
>>>> Without 2, T5 can hardly be considered top-level (even if on the
>>>> technical point of vue, it's completly rigth and it's IE fault),
>>>> without
>>>> 3, AJAX seems not so well integrated, and it's hot stuff todays, and 4
>>>> is so much common in a application, why do we have to bother with that
>>>> each time ?
>>>>
>>>> Other simple stuff that should be corrected before 5.0 (in my
>>>> opinion) :
>>>> - why hidden field is still missing ? It's so easy to add, a new user
>>>> should not even have to search for that !
>>>> - https://issues.apache.org/jira/browse/TAP5-257, that seems to bring
>>>> other pb with decorator and the like ;
>>>>
>>>
>>> Personally, I can live with all of those points except the localization
>>> issues. On the other hand I think that most of your points can be
>>> solved
>>> without much effort and therefore should be considered for the final
>>> release.
>>>
>>> Cheers,
>>>
>>> Uli
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
--
SU3 Analytics Ltd
61b Oxford Gardens
W10 5UJ
London
Tel: +44 20 8960 2634
Mob: +44 75 2501 0825
www.su3analytics.com
SU3 Analytics Ltd is a company registered in England and Wales under company number 06639473 at registered address 61b Oxford Gardens, London W10 5UJ, United Kingdom.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] What is your missing feature / bloking bug before 5.0 ?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Fri, 10 Oct 2008 10:37:54 -0300, Joel Halbert <jo...@su3analytics.com>
escreveu:
> I tend to try and keep all my pages as stateless as possible,
The pages I was referring to *are* stateless. ;) Of course, page
requirements vary depending on their functionalities. :)
--
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: [T5] What is your missing feature / bloking bug before 5.0 ?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Sat, 11 Oct 2008 12:32:53 -0300, Tobias Wehrum <Le...@dragonlab.de>
escreveu:
> Hi Thiago,
Hi!
>> You don't need to use the list binding. Just use the prop binding: [...]
>
> building the context in the java class seems somewhat cumbersomely to
> me, and also a bit confusing, since you cannot directly see what context
> the PageLink gets and have to lookup the method in the corresponding
> java method. Are there any advantages I don't see?
The advantage is that the activation context can be dynamic, being
generated in any way you like.
> I know, since I opened a few myself. It just seemed that Joel Halbert
> knows what he talks about, in contrast to me just thinking "having any
> sort of named context parameters (though I don't know how they would
> look like?) would be great" - which doesn't qualify as a text for a JIRA
> issue, I hope. :)
As long as you explain what named context parameters are and why would you
want them, I think it qualifies. :)
--
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: [T5] What is your missing feature / bloking bug before 5.0 ?
Posted by Tobias Wehrum <Le...@dragonlab.de>.
Hi Thiago,
> You don't need to use the list binding. Just use the prop binding: [...]
building the context in the java class seems somewhat cumbersomely to
me, and also a bit confusing, since you cannot directly see what context
the PageLink gets and have to lookup the method in the corresponding
java method. Are there any advantages I don't see?
>> There doesn't seem to be a JIRA feature request yet - do you mind
>> opening one? You have my vote for it.
> Everyone can open a JIRA issue (including feature requests). Just
> create an account there.
I know, since I opened a few myself. It just seemed that Joel Halbert
knows what he talks about, in contrast to me just thinking "having any
sort of named context parameters (though I don't know how they would
look like?) would be great" - which doesn't qualify as a text for a JIRA
issue, I hope. :)
- Tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] What is your missing feature / bloking bug before 5.0 ?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Fri, 10 Oct 2008 18:55:14 -0300, Tobias Wehrum <Le...@dragonlab.de>
escreveu:
> Same here. We have some sites too which need several parameters, and
> furthermore not all of them are set at any given time. The list: Binding
> used with null for empty parameters is an okay workaround, but having
> any sort of named context parameters (though I don't know how they would
> look like?) would be great.
You don't need to use the list binding. Just use the prop binding:
<a href="#" t:type="PageLink" t:page="page"
t:context="prop:context">...</a>
Actually, you don't even need to specify the prop:binding, as it is the
default for the context parameter.
Then provide a getter in your page class:
public List getContext() {
return ...;
}
> There doesn't seem to be a JIRA feature request yet - do you mind
> opening one? You have my vote for it.
Everyone can open a JIRA issue (including feature requests). Just create
an account there.
--
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: [T5] What is your missing feature / bloking bug before 5.0 ?
Posted by Tobias Wehrum <Le...@dragonlab.de>.
Same here. We have some sites too which need several parameters, and
furthermore not all of them are set at any given time. The list: Binding
used with null for empty parameters is an okay workaround, but having
any sort of named context parameters (though I don't know how they would
look like?) would be great. There doesn't seem to be a JIRA feature
request yet - do you mind opening one? You have my vote for it.
- Tobias
Joel Halbert schrieb:
> I tend to try and keep all my pages as stateless as possible, you can
> then quite easily require a few query string parameters per page when
> this is the case, consider the case of browsing a storefront - you
> need a "category id" (e.g. books, shoes), a page number (for the
> current page if looking at paginated data) and a "sort by" field (for
> the clients sort by selection). Already we have 3. There can easily be
> more, say if the client is "filtering" the view.
>
> Thiago H. de Paula Figueiredo wrote:
>> Em Fri, 10 Oct 2008 09:58:23 -0300, Joel Halbert
>> <jo...@su3analytics.com> escreveu:
>>
>>> I was wondering whether anyone missed the lack of direct support for
>>> named context parameters?
>>> I try to keep my pages as stateless as possible (thus bookmarkable)
>>> and better support for "named" context variables would make this
>>> much easier.
>>
>> I haven't missed named context parameters because my pages, almost
>> all the time, need just one parameter, sometimes two, so there is no
>> need to name them.
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] What is your missing feature / bloking bug before 5.0 ?
Posted by Ivan Dubrov <wf...@gmail.com>.
Geoff Callender wrote:
> Hi Joel,
>
> The activation context is great for passing object ids (or entity
> ids), and with database backed applications that is exactly what you'd
> be doing most of the time. The notion behind REST is that each URL
> represents a resource, which is pretty much what ids represent too.
>
> I agree that it would be good to be able to turn on
> name/value/name/value URLs built automatically by Tapestry, but only
> for resource-style URLs (which is what REST is all about).
>
> Filter criteria, however, I think deserve different treatment, ie.they
> should be added as a query string. I thoroughly agree that it would
> be good if T5 provided a formalised way of handling this difference
> that didn't involve us building our own Links.
I think, they basically could be handled the same way as regular
activation context. There could be two event methods, Map<String,
Object> onPassivateParameters()/onActivateParameters(Map<String, Object>
params) with similar meaning to onActivate and onPassivate. Also, there
could be an annotation @QueryParameter, which will work the same way as
@PageActivationContext.
I’ve already implemented something similar, I described the idea here:
http://www.nabble.com/Re%3A-%22named%22-page-context-parameters---p19893835.html
Hovewer, this solution is limited in several aspects.
First of all, you cannot override the parameters the same way you can
override the activation context in the resources.create*Link() calls.
That makes generating the links a bit more cumbersome (you have to save
old value of field marked by @QueryParameter, then set value you need,
then generate link and finally restore the previous field value).
Secondly, the framework does not allows specifying empty parameter
values. For example, I want “/orders” to works the same as
“/orders?status=NEW” and “/orders?status=” to show all orders (not only
new).
And finally, Tapestry does not allow having multiple parameters with
same name (for example, “/orders&status=NEW&status=REJECTED”, which is
correct URL).
>
> BTW, the current options are on demonstration at
> http://202.177.217.122:8080/jumpstart/examples/state/passingdatabetweenpages1
>
>
> Cheers,
>
> Geoff
>
> On 13/10/2008, at 12:08 AM, Joel Halbert wrote:
>
>> I'm a new T5 user so wasn't familiar with the pattern below for
>> adding params to links, I'll definitely try it out.
>>
>> However, If you go down the route you suggest below for passing
>> parameters between page, then what is the true value in the
>> activation context in the first place other than for the most simple
>> of requirements - (given that it seems unwieldy for large numbers of
>> parameters) ?
>>
>> Additionally, I would suggest that *how* activation context
>> parameters are encoded onto the URL should be configurable, so you
>> could choose to encode your activation parameters like this a/b/c/d
>> or like this a=b&c=d , or any other encoding mechanism you want.
>>
>> I really want to like the T5 framework, and in my limited experience
>> (4 days!) I think I do, especially because it seems much leaner and
>> more scalable than say Wicket, something I have used more extensively
>> and which because of its component based nature, and lack of page
>> pooling, creates and enormous amount of objects per page request
>> which then need to be cleaned up - a bit wasteful if you are only
>> creating stateless pages.
>> However I was quite suprised by what that I saw as a gap in native
>> (out the box & convenient & maintainable) support for truly stateless
>> pages in T5. As a stop gap I have got round the problem by writing a
>> custom ValueEncoder to encode and decode HashMap objects onto the
>> activation context, as a string like this key1_value1_key2_value2
>> etc, that way I work within the framework but with full support for
>> named parameters.
>>
>> I think the ideal solution (for an end user at least!) would be to
>> make it such that the @Persist("client") notation did all the hard
>> work of encoding primitive params on to a query sting, but more
>> concisely that it currently does
>>
>> i.e. what cann't a primitive variable such as
>>
>> @Persist("client")
>> private String name;
>>
>> be simply encoded onto the url as "name=value" rather than the
>> current solution of an enourmously long encoded value?
>> If this were to happen then I think T5 really would be a truly great
>> framework!
>>
>> Thx,
>> Joel
>>
>>
>> Geoff Callender wrote:
>>> I'm not keen on the named context parameters idea. There's a
>>> persuasive argument for putting filter parameters into the query
>>> string portion of the URL instead of in the context.
>>> http://blpsilva.wordpress.com/2008/04/05/query-strings-in-restful-web-services/
>>>
>>>
>>> So you get a URL like this
>>> http://localhost:8080/myapp/mypage?firstname=Humpty&lastname=Dumpty
>>> instead of this
>>> http://localhost:8080/myapp/mypage/firstname/Humpty/lastname/Dumpty
>>>
>>> It's easy enough to do:
>>> @Inject
>>> private ComponentResources _componentResources;
>>>
>>> @Inject
>>> private Request _request;
>>>
>>> public Link set(String firstName, String lastName) {
>>> Link link =
>>> _componentResources.createPageLink(this.getClass(), true);
>>>
>>> if (firstName != null) {
>>> link.addParameter("firstname", firstName);
>>> }
>>> if (lastName != null) {
>>> link.addParameter("lastname", lastName);
>>> }
>>> return link;
>>> }
>>>
>>> void onActivate() {
>>> _firstName = _request.getParameter("firstname");
>>> _lastName = _request.getParameter("lastname");
>>> }
>>>
>>> On 11/10/2008, at 12:37 AM, Joel Halbert wrote:
>>>
>>>> I tend to try and keep all my pages as stateless as possible, you
>>>> can then quite easily require a few query string parameters per
>>>> page when this is the case, consider the case of browsing a
>>>> storefront - you need a "category id" (e.g. books, shoes), a page
>>>> number (for the current page if looking at paginated data) and a
>>>> "sort by" field (for the clients sort by selection). Already we
>>>> have 3. There can easily be more, say if the client is "filtering"
>>>> the view.
>>>>
>>>> Thiago H. de Paula Figueiredo wrote:
>>>>> Em Fri, 10 Oct 2008 09:58:23 -0300, Joel Halbert
>>>>> <jo...@su3analytics.com> escreveu:
>>>>>
>>>>>> I was wondering whether anyone missed the lack of direct support
>>>>>> for named context parameters?
>>>>>> I try to keep my pages as stateless as possible (thus
>>>>>> bookmarkable) and better support for "named" context variables
>>>>>> would make this much easier.
>>>>>
>>>>> I haven't missed named context parameters because my pages, almost
>>>>> all the time, need just one parameter, sometimes two, so there is
>>>>> no need to name them.
>>>>>
>>>>
>>>> --
>>>> SU3 Analytics Ltd
>>>> 61b Oxford Gardens
>>>> W10 5UJ
>>>> London
>>>>
>>>> Tel: +44 20 8960 2634
>>>> Mob: +44 75 2501 0825
>>>> www.su3analytics.com
>>>>
>>>> SU3 Analytics Ltd is a company registered in England and Wales
>>>> under company number 06639473 at registered address 61b Oxford
>>>> Gardens, London W10 5UJ, United Kingdom.
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>
>>>
>>
>> --
>> SU3 Analytics Ltd
>> 61b Oxford Gardens
>> W10 5UJ
>> London
>>
>> Tel: +44 20 8960 2634
>> Mob: +44 75 2501 0825
>> www.su3analytics.com
>>
>> SU3 Analytics Ltd is a company registered in England and Wales under
>> company number 06639473 at registered address 61b Oxford Gardens,
>> London W10 5UJ, United Kingdom.
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
--
WBR,
Ivan S. Dubrov
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] What is your missing feature / bloking bug before 5.0 ?
Posted by Geoff Callender <ge...@gmail.com>.
Hi Joel,
The activation context is great for passing object ids (or entity
ids), and with database backed applications that is exactly what you'd
be doing most of the time. The notion behind REST is that each URL
represents a resource, which is pretty much what ids represent too.
I agree that it would be good to be able to turn on name/value/name/
value URLs built automatically by Tapestry, but only for resource-
style URLs (which is what REST is all about).
Filter criteria, however, I think deserve different treatment, ie.they
should be added as a query string. I thoroughly agree that it would
be good if T5 provided a formalised way of handling this difference
that didn't involve us building our own Links.
BTW, the current options are on demonstration at http://202.177.217.122:8080/jumpstart/examples/state/passingdatabetweenpages1
Cheers,
Geoff
On 13/10/2008, at 12:08 AM, Joel Halbert wrote:
> I'm a new T5 user so wasn't familiar with the pattern below for
> adding params to links, I'll definitely try it out.
>
> However, If you go down the route you suggest below for passing
> parameters between page, then what is the true value in the
> activation context in the first place other than for the most simple
> of requirements - (given that it seems unwieldy for large numbers of
> parameters) ?
>
> Additionally, I would suggest that *how* activation context
> parameters are encoded onto the URL should be configurable, so you
> could choose to encode your activation parameters like this a/b/c/d
> or like this a=b&c=d , or any other encoding mechanism you want.
>
> I really want to like the T5 framework, and in my limited experience
> (4 days!) I think I do, especially because it seems much leaner and
> more scalable than say Wicket, something I have used more
> extensively and which because of its component based nature, and
> lack of page pooling, creates and enormous amount of objects per
> page request which then need to be cleaned up - a bit wasteful if
> you are only creating stateless pages.
> However I was quite suprised by what that I saw as a gap in native
> (out the box & convenient & maintainable) support for truly
> stateless pages in T5. As a stop gap I have got round the problem by
> writing a custom ValueEncoder to encode and decode HashMap objects
> onto the activation context, as a string like this
> key1_value1_key2_value2 etc, that way I work within the framework
> but with full support for named parameters.
>
> I think the ideal solution (for an end user at least!) would be to
> make it such that the @Persist("client") notation did all the hard
> work of encoding primitive params on to a query sting, but more
> concisely that it currently does
>
> i.e. what cann't a primitive variable such as
>
> @Persist("client")
> private String name;
>
> be simply encoded onto the url as "name=value" rather than the
> current solution of an enourmously long encoded value?
> If this were to happen then I think T5 really would be a truly great
> framework!
>
> Thx,
> Joel
>
>
> Geoff Callender wrote:
>> I'm not keen on the named context parameters idea. There's a
>> persuasive argument for putting filter parameters into the query
>> string portion of the URL instead of in the context. http://blpsilva.wordpress.com/2008/04/05/query-strings-in-restful-web-services/
>>
>> So you get a URL like this http://localhost:8080/myapp/mypage?firstname=Humpty&lastname=Dumpty
>> instead of this http://localhost:8080/myapp/mypage/firstname/Humpty/lastname/Dumpty
>>
>> It's easy enough to do:
>> @Inject
>> private ComponentResources _componentResources;
>>
>> @Inject
>> private Request _request;
>>
>> public Link set(String firstName, String lastName) {
>> Link link =
>> _componentResources.createPageLink(this.getClass(), true);
>>
>> if (firstName != null) {
>> link.addParameter("firstname", firstName);
>> }
>> if (lastName != null) {
>> link.addParameter("lastname", lastName);
>> }
>> return link;
>> }
>>
>> void onActivate() {
>> _firstName = _request.getParameter("firstname");
>> _lastName = _request.getParameter("lastname");
>> }
>>
>> On 11/10/2008, at 12:37 AM, Joel Halbert wrote:
>>
>>> I tend to try and keep all my pages as stateless as possible, you
>>> can then quite easily require a few query string parameters per
>>> page when this is the case, consider the case of browsing a
>>> storefront - you need a "category id" (e.g. books, shoes), a page
>>> number (for the current page if looking at paginated data) and a
>>> "sort by" field (for the clients sort by selection). Already we
>>> have 3. There can easily be more, say if the client is "filtering"
>>> the view.
>>>
>>> Thiago H. de Paula Figueiredo wrote:
>>>> Em Fri, 10 Oct 2008 09:58:23 -0300, Joel Halbert <joel@su3analytics.com
>>>> > escreveu:
>>>>
>>>>> I was wondering whether anyone missed the lack of direct support
>>>>> for named context parameters?
>>>>> I try to keep my pages as stateless as possible (thus
>>>>> bookmarkable) and better support for "named" context variables
>>>>> would make this much easier.
>>>>
>>>> I haven't missed named context parameters because my pages,
>>>> almost all the time, need just one parameter, sometimes two, so
>>>> there is no need to name them.
>>>>
>>>
>>> --
>>> SU3 Analytics Ltd
>>> 61b Oxford Gardens
>>> W10 5UJ
>>> London
>>>
>>> Tel: +44 20 8960 2634
>>> Mob: +44 75 2501 0825
>>> www.su3analytics.com
>>>
>>> SU3 Analytics Ltd is a company registered in England and Wales
>>> under company number 06639473 at registered address 61b Oxford
>>> Gardens, London W10 5UJ, United Kingdom.
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>
>>
>
> --
> SU3 Analytics Ltd
> 61b Oxford Gardens
> W10 5UJ
> London
>
> Tel: +44 20 8960 2634
> Mob: +44 75 2501 0825
> www.su3analytics.com
>
> SU3 Analytics Ltd is a company registered in England and Wales under
> company number 06639473 at registered address 61b Oxford Gardens,
> London W10 5UJ, United Kingdom.
>
>
>
> ---------------------------------------------------------------------
> 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: [T5] What is your missing feature / bloking bug before 5.0 ?
Posted by Joel Halbert <jo...@su3analytics.com>.
I'm a new T5 user so wasn't familiar with the pattern below for adding
params to links, I'll definitely try it out.
However, If you go down the route you suggest below for passing
parameters between page, then what is the true value in the activation
context in the first place other than for the most simple of
requirements - (given that it seems unwieldy for large numbers of
parameters) ?
Additionally, I would suggest that *how* activation context parameters
are encoded onto the URL should be configurable, so you could choose to
encode your activation parameters like this a/b/c/d or like this a=b&c=d
, or any other encoding mechanism you want.
I really want to like the T5 framework, and in my limited experience (4
days!) I think I do, especially because it seems much leaner and more
scalable than say Wicket, something I have used more extensively and
which because of its component based nature, and lack of page pooling,
creates and enormous amount of objects per page request which then need
to be cleaned up - a bit wasteful if you are only creating stateless pages.
However I was quite suprised by what that I saw as a gap in native (out
the box & convenient & maintainable) support for truly stateless pages
in T5. As a stop gap I have got round the problem by writing a custom
ValueEncoder to encode and decode HashMap objects onto the activation
context, as a string like this key1_value1_key2_value2 etc, that way I
work within the framework but with full support for named parameters.
I think the ideal solution (for an end user at least!) would be to make
it such that the @Persist("client") notation did all the hard work of
encoding primitive params on to a query sting, but more concisely that
it currently does
i.e. what cann't a primitive variable such as
@Persist("client")
private String name;
be simply encoded onto the url as "name=value" rather than the current
solution of an enourmously long encoded value?
If this were to happen then I think T5 really would be a truly great
framework!
Thx,
Joel
Geoff Callender wrote:
> I'm not keen on the named context parameters idea. There's a
> persuasive argument for putting filter parameters into the query
> string portion of the URL instead of in the context.
> http://blpsilva.wordpress.com/2008/04/05/query-strings-in-restful-web-services/
>
>
> So you get a URL like this
> http://localhost:8080/myapp/mypage?firstname=Humpty&lastname=Dumpty
> instead of this
> http://localhost:8080/myapp/mypage/firstname/Humpty/lastname/Dumpty
>
> It's easy enough to do:
> @Inject
> private ComponentResources _componentResources;
>
> @Inject
> private Request _request;
>
> public Link set(String firstName, String lastName) {
> Link link =
> _componentResources.createPageLink(this.getClass(), true);
>
> if (firstName != null) {
> link.addParameter("firstname", firstName);
> }
> if (lastName != null) {
> link.addParameter("lastname", lastName);
> }
>
> return link;
> }
>
> void onActivate() {
> _firstName = _request.getParameter("firstname");
> _lastName = _request.getParameter("lastname");
> }
>
> On 11/10/2008, at 12:37 AM, Joel Halbert wrote:
>
>> I tend to try and keep all my pages as stateless as possible, you can
>> then quite easily require a few query string parameters per page when
>> this is the case, consider the case of browsing a storefront - you
>> need a "category id" (e.g. books, shoes), a page number (for the
>> current page if looking at paginated data) and a "sort by" field (for
>> the clients sort by selection). Already we have 3. There can easily
>> be more, say if the client is "filtering" the view.
>>
>> Thiago H. de Paula Figueiredo wrote:
>>> Em Fri, 10 Oct 2008 09:58:23 -0300, Joel Halbert
>>> <jo...@su3analytics.com> escreveu:
>>>
>>>> I was wondering whether anyone missed the lack of direct support
>>>> for named context parameters?
>>>> I try to keep my pages as stateless as possible (thus bookmarkable)
>>>> and better support for "named" context variables would make this
>>>> much easier.
>>>
>>> I haven't missed named context parameters because my pages, almost
>>> all the time, need just one parameter, sometimes two, so there is no
>>> need to name them.
>>>
>>
>> --
>> SU3 Analytics Ltd
>> 61b Oxford Gardens
>> W10 5UJ
>> London
>>
>> Tel: +44 20 8960 2634
>> Mob: +44 75 2501 0825
>> www.su3analytics.com
>>
>> SU3 Analytics Ltd is a company registered in England and Wales under
>> company number 06639473 at registered address 61b Oxford Gardens,
>> London W10 5UJ, United Kingdom.
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
>
--
SU3 Analytics Ltd
61b Oxford Gardens
W10 5UJ
London
Tel: +44 20 8960 2634
Mob: +44 75 2501 0825
www.su3analytics.com
SU3 Analytics Ltd is a company registered in England and Wales under company number 06639473 at registered address 61b Oxford Gardens, London W10 5UJ, United Kingdom.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] What is your missing feature / bloking bug before 5.0 ?
Posted by Geoff Callender <ge...@gmail.com>.
I'm not keen on the named context parameters idea. There's a
persuasive argument for putting filter parameters into the query
string portion of the URL instead of in the context. http://blpsilva.wordpress.com/2008/04/05/query-strings-in-restful-web-services/
So you get a URL like this http://localhost:8080/myapp/mypage?firstname=Humpty&lastname=Dumpty
instead of this http://localhost:8080/myapp/mypage/firstname/Humpty/lastname/Dumpty
It's easy enough to do:
@Inject
private ComponentResources _componentResources;
@Inject
private Request _request;
public Link set(String firstName, String lastName) {
Link link = _componentResources.createPageLink(this.getClass(), true);
if (firstName != null) {
link.addParameter("firstname", firstName);
}
if (lastName != null) {
link.addParameter("lastname", lastName);
}
return link;
}
void onActivate() {
_firstName = _request.getParameter("firstname");
_lastName = _request.getParameter("lastname");
}
On 11/10/2008, at 12:37 AM, Joel Halbert wrote:
> I tend to try and keep all my pages as stateless as possible, you
> can then quite easily require a few query string parameters per page
> when this is the case, consider the case of browsing a storefront -
> you need a "category id" (e.g. books, shoes), a page number (for the
> current page if looking at paginated data) and a "sort by" field
> (for the clients sort by selection). Already we have 3. There can
> easily be more, say if the client is "filtering" the view.
>
> Thiago H. de Paula Figueiredo wrote:
>> Em Fri, 10 Oct 2008 09:58:23 -0300, Joel Halbert <joel@su3analytics.com
>> > escreveu:
>>
>>> I was wondering whether anyone missed the lack of direct support
>>> for named context parameters?
>>> I try to keep my pages as stateless as possible (thus
>>> bookmarkable) and better support for "named" context variables
>>> would make this much easier.
>>
>> I haven't missed named context parameters because my pages, almost
>> all the time, need just one parameter, sometimes two, so there is
>> no need to name them.
>>
>
> --
> SU3 Analytics Ltd
> 61b Oxford Gardens
> W10 5UJ
> London
>
> Tel: +44 20 8960 2634
> Mob: +44 75 2501 0825
> www.su3analytics.com
>
> SU3 Analytics Ltd is a company registered in England and Wales under
> company number 06639473 at registered address 61b Oxford Gardens,
> London W10 5UJ, United Kingdom.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
Re: [T5] What is your missing feature / bloking bug before 5.0 ?
Posted by Joel Halbert <jo...@su3analytics.com>.
I tend to try and keep all my pages as stateless as possible, you can
then quite easily require a few query string parameters per page when
this is the case, consider the case of browsing a storefront - you need
a "category id" (e.g. books, shoes), a page number (for the current page
if looking at paginated data) and a "sort by" field (for the clients
sort by selection). Already we have 3. There can easily be more, say if
the client is "filtering" the view.
Thiago H. de Paula Figueiredo wrote:
> Em Fri, 10 Oct 2008 09:58:23 -0300, Joel Halbert
> <jo...@su3analytics.com> escreveu:
>
>> I was wondering whether anyone missed the lack of direct support for
>> named context parameters?
>> I try to keep my pages as stateless as possible (thus bookmarkable)
>> and better support for "named" context variables would make this much
>> easier.
>
> I haven't missed named context parameters because my pages, almost all
> the time, need just one parameter, sometimes two, so there is no need
> to name them.
>
--
SU3 Analytics Ltd
61b Oxford Gardens
W10 5UJ
London
Tel: +44 20 8960 2634
Mob: +44 75 2501 0825
www.su3analytics.com
SU3 Analytics Ltd is a company registered in England and Wales under company number 06639473 at registered address 61b Oxford Gardens, London W10 5UJ, United Kingdom.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] What is your missing feature / bloking bug before 5.0 ?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Fri, 10 Oct 2008 09:58:23 -0300, Joel Halbert <jo...@su3analytics.com>
escreveu:
> I was wondering whether anyone missed the lack of direct support for
> named context parameters?
> I try to keep my pages as stateless as possible (thus bookmarkable) and
> better support for "named" context variables would make this much easier.
I haven't missed named context parameters because my pages, almost all the
time, need just one parameter, sometimes two, so there is no need to name
them.
--
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: [T5] What is your missing feature / bloking bug before 5.0 ?
Posted by Joel Halbert <jo...@su3analytics.com>.
I was wondering whether anyone missed the lack of direct support for
named context parameters?
I try to keep my pages as stateless as possible (thus bookmarkable) and
better support for "named" context variables would make this much easier.
José Paumard wrote:
> François,
>
> I think we all agree that T5 is an outstanding framework on many
> points. I've been using it for nearly a year now, with great pleasure
> and satisfactions.
>
> May I add those two issues :
> https://issues.apache.org/jira/browse/TAPESTRY-2433
> I reported this bug quite some time ago, Howard closed it when v0.15
> got UTF8, but in fact it's still here.
>
> And another one (https://issues.apache.org/jira/browse/TAPESTRY-2432),
> that really hinders the concept of customized property editor. This
> concept is very powerful : build your own property editor, put your
> beans in a bean editor, and everything works flawlessly (and it does
> !). But when your property spans over more than one basic component
> (and which one doesnt ? if is was a simple property, why would you be
> writing an editor for it ?), you cant have some of your code executed
> between the injection of the form values in your editor, and the
> reading of the edited property by T5 (T5 doesnt use the getter /
> setter stuff to read / write those properties). So you have no way to
> cleanly build your property object from the values in the HTML form.
>
> And the third one (remember the spanish inquisition ? ;))
>
> Please, ho please, remove that hard coded "There is no data to
> display." from Grid.tml !
>
> Thank you,
>
> José
>
> Ulrich Stärk a écrit :
>> Am Fr, 10.10.2008, 10:56, schrieb Francois Armand:
>>
>>> Ok, so we reach the point where T5.0 final is imminent, and we are all
>>> (I think) really happy of that.
>>> As we also want that T5 really makes its way in the Java Web ecosystem,
>>> I think it always miss some really little things that are really
>>> important for a .0 release.
>>>
>>> I purpose to start this discussion in the ml, and when some major gap
>>> emerge, to post them in the issue tracker, and vote for them.
>>>
>>> So, for me, what I expect for 5.0 :
>>> 1/ - full and complete and rather simple internationalization : I
>>> really
>>> believe that a web framework can ignore other language and culture
>>> (date, number) today ;
>>> that include validator translation and stuff like that.
>>>
>>
>> I believe you meant "can't" ;-)
>>
>> https://issues.apache.org/jira/browse/TAP5-211
>>
>> This is the thing I care the most about as there is no workaround
>> without
>> breaking other things.
>>
>>
>>
>>> 2/ - valid XHTML, even for IE, by default. The workaround is here for
>>> some time, but why it's not default ? See
>>> http://wiki.apache.org/tapestry/Tapestry5HowToXhtml
>>> 3/ - something around AJAX documentation and Zone update inside a form
>>> (that includes update of part of a form on change from a select :
>>> https://issues.apache.org/jira/browse/TAP5-138)
>>>
>>
>> That seems to be a very frequent use case and should really be
>> implemented
>> soon.
>>
>>
>>> 4/- a property symbol provider, also simple and in use almost always
>>> @see
>>> http://wiki.apache.org/tapestry/Tapestry5HowToReadSymbolsFromPropertiesFile
>>>
>>>
>>
>> I think this is not that important to have. There is a simple
>> solution in
>> the wiki that people can refactor into a module, put it in a jar file
>> and
>> drop it into their projects as needed. On the other hand this
>> wouldn't be
>> too complicated to integrate into the core distribution, given that the
>> code already exists.
>>
>>
>>> Without 1, T5 just can't get is path easely outside English contries ;
>>> Without 2, T5 can hardly be considered top-level (even if on the
>>> technical point of vue, it's completly rigth and it's IE fault),
>>> without
>>> 3, AJAX seems not so well integrated, and it's hot stuff todays, and 4
>>> is so much common in a application, why do we have to bother with that
>>> each time ?
>>>
>>> Other simple stuff that should be corrected before 5.0 (in my
>>> opinion) :
>>> - why hidden field is still missing ? It's so easy to add, a new user
>>> should not even have to search for that !
>>> - https://issues.apache.org/jira/browse/TAP5-257, that seems to bring
>>> other pb with decorator and the like ;
>>>
>>
>> Personally, I can live with all of those points except the localization
>> issues. On the other hand I think that most of your points can be solved
>> without much effort and therefore should be considered for the final
>> release.
>>
>> Cheers,
>>
>> Uli
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
--
SU3 Analytics Ltd
61b Oxford Gardens
W10 5UJ
London
Tel: +44 20 8960 2634
Mob: +44 75 2501 0825
www.su3analytics.com
SU3 Analytics Ltd is a company registered in England and Wales under company number 06639473 at registered address 61b Oxford Gardens, London W10 5UJ, United Kingdom.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] What is your missing feature / bloking bug before 5.0 ?
Posted by José Paumard <Jo...@orange.fr>.
François,
I think we all agree that T5 is an outstanding framework on many points.
I've been using it for nearly a year now, with great pleasure and
satisfactions.
May I add those two issues :
https://issues.apache.org/jira/browse/TAPESTRY-2433
I reported this bug quite some time ago, Howard closed it when v0.15 got
UTF8, but in fact it's still here.
And another one (https://issues.apache.org/jira/browse/TAPESTRY-2432),
that really hinders the concept of customized property editor. This
concept is very powerful : build your own property editor, put your
beans in a bean editor, and everything works flawlessly (and it does !).
But when your property spans over more than one basic component (and
which one doesnt ? if is was a simple property, why would you be writing
an editor for it ?), you cant have some of your code executed between
the injection of the form values in your editor, and the reading of the
edited property by T5 (T5 doesnt use the getter / setter stuff to read /
write those properties). So you have no way to cleanly build your
property object from the values in the HTML form.
And the third one (remember the spanish inquisition ? ;))
Please, ho please, remove that hard coded "There is no data to display."
from Grid.tml !
Thank you,
José
Ulrich Stärk a écrit :
> Am Fr, 10.10.2008, 10:56, schrieb Francois Armand:
>
>> Ok, so we reach the point where T5.0 final is imminent, and we are all
>> (I think) really happy of that.
>> As we also want that T5 really makes its way in the Java Web ecosystem,
>> I think it always miss some really little things that are really
>> important for a .0 release.
>>
>> I purpose to start this discussion in the ml, and when some major gap
>> emerge, to post them in the issue tracker, and vote for them.
>>
>> So, for me, what I expect for 5.0 :
>> 1/ - full and complete and rather simple internationalization : I really
>> believe that a web framework can ignore other language and culture
>> (date, number) today ;
>> that include validator translation and stuff like that.
>>
>
> I believe you meant "can't" ;-)
>
> https://issues.apache.org/jira/browse/TAP5-211
>
> This is the thing I care the most about as there is no workaround without
> breaking other things.
>
>
>
>> 2/ - valid XHTML, even for IE, by default. The workaround is here for
>> some time, but why it's not default ? See
>> http://wiki.apache.org/tapestry/Tapestry5HowToXhtml
>> 3/ - something around AJAX documentation and Zone update inside a form
>> (that includes update of part of a form on change from a select :
>> https://issues.apache.org/jira/browse/TAP5-138)
>>
>
> That seems to be a very frequent use case and should really be implemented
> soon.
>
>
>> 4/- a property symbol provider, also simple and in use almost always
>> @see
>> http://wiki.apache.org/tapestry/Tapestry5HowToReadSymbolsFromPropertiesFile
>>
>
> I think this is not that important to have. There is a simple solution in
> the wiki that people can refactor into a module, put it in a jar file and
> drop it into their projects as needed. On the other hand this wouldn't be
> too complicated to integrate into the core distribution, given that the
> code already exists.
>
>
>> Without 1, T5 just can't get is path easely outside English contries ;
>> Without 2, T5 can hardly be considered top-level (even if on the
>> technical point of vue, it's completly rigth and it's IE fault), without
>> 3, AJAX seems not so well integrated, and it's hot stuff todays, and 4
>> is so much common in a application, why do we have to bother with that
>> each time ?
>>
>> Other simple stuff that should be corrected before 5.0 (in my opinion) :
>> - why hidden field is still missing ? It's so easy to add, a new user
>> should not even have to search for that !
>> - https://issues.apache.org/jira/browse/TAP5-257, that seems to bring
>> other pb with decorator and the like ;
>>
>
> Personally, I can live with all of those points except the localization
> issues. On the other hand I think that most of your points can be solved
> without much effort and therefore should be considered for the final
> release.
>
> Cheers,
>
> Uli
>
>
> ---------------------------------------------------------------------
> 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: [T5] What is your missing feature / bloking bug before 5.0 ?
Posted by Ulrich Stärk <ul...@spielviel.de>.
Am Fr, 10.10.2008, 10:56, schrieb Francois Armand:
> Ok, so we reach the point where T5.0 final is imminent, and we are all
> (I think) really happy of that.
> As we also want that T5 really makes its way in the Java Web ecosystem,
> I think it always miss some really little things that are really
> important for a .0 release.
>
> I purpose to start this discussion in the ml, and when some major gap
> emerge, to post them in the issue tracker, and vote for them.
>
> So, for me, what I expect for 5.0 :
> 1/ - full and complete and rather simple internationalization : I really
> believe that a web framework can ignore other language and culture
> (date, number) today ;
> that include validator translation and stuff like that.
I believe you meant "can't" ;-)
https://issues.apache.org/jira/browse/TAP5-211
This is the thing I care the most about as there is no workaround without
breaking other things.
> 2/ - valid XHTML, even for IE, by default. The workaround is here for
> some time, but why it's not default ? See
> http://wiki.apache.org/tapestry/Tapestry5HowToXhtml
> 3/ - something around AJAX documentation and Zone update inside a form
> (that includes update of part of a form on change from a select :
> https://issues.apache.org/jira/browse/TAP5-138)
That seems to be a very frequent use case and should really be implemented
soon.
> 4/- a property symbol provider, also simple and in use almost always
> @see
> http://wiki.apache.org/tapestry/Tapestry5HowToReadSymbolsFromPropertiesFile
I think this is not that important to have. There is a simple solution in
the wiki that people can refactor into a module, put it in a jar file and
drop it into their projects as needed. On the other hand this wouldn't be
too complicated to integrate into the core distribution, given that the
code already exists.
>
> Without 1, T5 just can't get is path easely outside English contries ;
> Without 2, T5 can hardly be considered top-level (even if on the
> technical point of vue, it's completly rigth and it's IE fault), without
> 3, AJAX seems not so well integrated, and it's hot stuff todays, and 4
> is so much common in a application, why do we have to bother with that
> each time ?
>
> Other simple stuff that should be corrected before 5.0 (in my opinion) :
> - why hidden field is still missing ? It's so easy to add, a new user
> should not even have to search for that !
> - https://issues.apache.org/jira/browse/TAP5-257, that seems to bring
> other pb with decorator and the like ;
Personally, I can live with all of those points except the localization
issues. On the other hand I think that most of your points can be solved
without much effort and therefore should be considered for the final
release.
Cheers,
Uli
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
AW: [T5] What is your missing feature / bloking bug before 5.0 ?
Posted by Maximilian Weißböck <Ma...@sphinx.at>.
As I have to support german localization and IE, I think
1) and 2) is a must have for 5.0
3) would be great, but is not a must have for 5.0 I think
I also think Geoff is right with is argument:
"ApplicationStateObject is a misleading term" https://issues.apache.org/jira/browse/TAPESTRY-2703
and this is the last change to fix it - and it should be fixed!
And not to forget: T5 really rocks!
best regards, Max
-----Ursprüngliche Nachricht-----
Von: Francois Armand [mailto:farmand@linagora.com]
Gesendet: Fr 10.10.2008 10:56
An: Tapestry users
Betreff: [T5] What is your missing feature / bloking bug before 5.0 ?
Ok, so we reach the point where T5.0 final is imminent, and we are all
(I think) really happy of that.
As we also want that T5 really makes its way in the Java Web ecosystem,
I think it always miss some really little things that are really
important for a .0 release.
I purpose to start this discussion in the ml, and when some major gap
emerge, to post them in the issue tracker, and vote for them.
So, for me, what I expect for 5.0 :
1/ - full and complete and rather simple internationalization : I really
believe that a web framework can ignore other language and culture
(date, number) today ;
that include validator translation and stuff like that.
2/ - valid XHTML, even for IE, by default. The workaround is here for
some time, but why it's not default ? See
http://wiki.apache.org/tapestry/Tapestry5HowToXhtml
3/ - something around AJAX documentation and Zone update inside a form
(that includes update of part of a form on change from a select :
https://issues.apache.org/jira/browse/TAP5-138)
4/- a property symbol provider, also simple and in use almost always
@see
http://wiki.apache.org/tapestry/Tapestry5HowToReadSymbolsFromPropertiesFile
Without 1, T5 just can't get is path easely outside English contries ;
Without 2, T5 can hardly be considered top-level (even if on the
technical point of vue, it's completly rigth and it's IE fault), without
3, AJAX seems not so well integrated, and it's hot stuff todays, and 4
is so much common in a application, why do we have to bother with that
each time ?
Other simple stuff that should be corrected before 5.0 (in my opinion) :
- why hidden field is still missing ? It's so easy to add, a new user
should not even have to search for that !
- https://issues.apache.org/jira/browse/TAP5-257, that seems to bring
other pb with decorator and the like ;
What do you thing about that ? Does it make sense to open a "community
want that" bug, that have to be quick to handle, but that brings the
attention of T5 developers on what we need ? Perhaps we can already vote
for existing bugs ? Which ones ?
--
Francois Armand
Etudes & Développements J2EE
Groupe Linagora - http://www.linagora.com
Tél.: +33 (0)1 58 18 68 28
-----------
InterLDAP - http://interldap.org
FederID - http://www.federid.org/
Open Source identities management and federation
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] What is your missing feature / bloking bug before 5.0 ?
Posted by Borut Bolčina <bo...@gmail.com>.
Hi,
this https://issues.apache.org/jira/browse/TAP5-245 (Better
documentation on development environment) is still opened and
http://tapestry.apache.org/tapestry5/tutorial1/env.html is outdated
and not covering some cases.
There has been numerous discussions on this list on several dev
setups, but as I already said - the newcomers expect to read this
stuff on the main T5 page.
Cheers,
Borut
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org