Actually, just:
@Inject
private Locale locale;
That's all you need. Tapestry finds or builds a page for the locale
specified in the request, so by the time your code gets invoked, the locale
is locked down.
On Fri, Dec 17, 2010 at 7:37 PM, Angelo C. wrote:
>
> looks like I did not search enou
looks like I did not search enough, turned out, should use:
@Inject
private ThreadLocale locale;
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/t5-getting-locale-in-a-page-class-tp3310211p3310214.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
hi,
How to get the locale in a page class? I have this code:
public Object onActivate(EventContext ec) {
System.out.println(request.getLocale().getLanguage());
return null;
}
this url returns 'en':
http://localhost
this url returns 'en' too, despite the page is already in Chine
You are on the right track. Look at this example:
http://jumpstart.doublenegative.com.au/jumpstart/examples/javascript/ajaxonevent
You'll have to make some changes to get it to work inside a form with a
variable number of items, but it should work with a multizone update.
Mark
On Fri, Dec 17,
For compatibility purposes, we would always be type compatible. :)
But introducing a general mechanism for component overriding could be tricky
because of the issue. I guess you could enforce type compatibility when the
components are overridden? Not sure what an "override" would look like...
In
On Fri, Dec 17, 2010 at 3:27 PM, Robert Zeigler wrote:
> Yeah, to be sure. That's why I like the tapestry-compatibility module
> idea you add it if you want full backwards compatibility. You leave it
> out if you don't need it/want the new behavior by default.
> Additionally, each compatibi
I have a shopping cart that looks like this:
Price | Qty | Cost | Description
--|-|--|
$5| 1 | $10 | Red Elmo
$10 | 2 | $20 | Green Elmo
(etc.)
Total: $30
The Qty field is editable by the user. I need to be able to tell when the user
updates the Qty update th
Yeah, to be sure. That's why I like the tapestry-compatibility module idea
you add it if you want full backwards compatibility. You leave it out if you
don't need it/want the new behavior by default.
Additionally, each compatibility module could contribute the
TAPESTRY_COMPATIBILITY symbol
Well, something that is deprecated with a replacement in Tapestry 5.(n)
might be removed in 5.(n+1), though I suspect most users would prefer to see
it live on to 5.(n+2).
On Fri, Dec 17, 2010 at 3:12 PM, Howard Lewis Ship wrote:
> It's a tricky situation; some users are going to want to upgrad
It's a tricky situation; some users are going to want to upgrade to 5.3 and
see new features and behaviors automatically; others will want to upgrade to
5.3 and see nothing change until they enable it.
I like the idea of factoring out as much as possible into
tapestry-compatibility.jar.
I think t
On Fri, Dec 17, 2010 at 2:25 PM, Robert Zeigler wrote:
> I'm thinking out loud here, but...
> Recently, I upgraded a project from 5.0.15 to 5.1.0.4. The project is fairly
> complex, and there were some major changes in Tapestry's behavior between
> 5.0.15 and 5.0.18, when the public apis were l
As you are all aware, Tapestry is an open source project, a labor of love
for the committers. The Tapestry committers and contributors work quite hard
to create the code, fix the bugs, add new features, write documentation, and
provide free support on the mailing list. It's not easy, and you'd be a
+1.
Although the question remains... how /long/ to be compatible. For instance,
you might want "5.0" in there, as well, in which case, the label-id generation
would need to be enabled for modes 5.0 and 5.1 (suggesting perhaps a need for
some conversion to an "ordered" value... something more th
Thank you I got the maven jetty plugin working with jetty 7.
On 15 December 2010 14:09, LLTYK wrote:
>
> This is for jetty 7. Jetty 6 has different package names, different plugin
> names, etc. A chore to switch between the two but much of the syntax is the
> same.
>
>
>
It was simply the case that the id wasn't needed, because the label could be
located as previously outlined.
Rather than have an endless number of switches to set, I think we may need a
global compatibility symbol ("tapestry.compatibility"), and maybe a
mechanism for turning that into a boolean at
Hmm...
The id needs to be put back, but before we add a symbol to allow it to
be optionally removed I'd like to make sure that Howard (and anyone
else) really needed it removed and it wasn't just some house cleaning.
I imagine if it was really a number of bytes issue then more than just
the label
On Dec 17, 2010, at 12/1712:53 PM , Thiago H. de Paula Figueiredo wrote:
> On Fri, 17 Dec 2010 16:35:43 -0200, Robert Zeigler wrote:
>
>> Just to clarify, I hope that by "true" you mean that id generation is turned
>> /on/ by default. :)
>
> Your hope isn't in vain. :) true = on in this case.
On Fri, 17 Dec 2010 16:35:43 -0200, Robert Zeigler
wrote:
Just to clarify, I hope that by "true" you mean that id generation is
turned /on/ by default. :)
Your hope isn't in vain. :) true = on in this case.
warnings as time allowed. The important thing is that even with
deprecated meth
Just to clarify, I hope that by "true" you mean that id generation is turned
/on/ by default. :) At least for 5.2.4. It could be off by default in 5.3. But
these sorts of seemingly innocuous but actually disruptive changes (and yes:
nixing the id of an element is a disruptive change!) should hap
On Fri, 17 Dec 2010 15:40:13 -0200, Andreas Andreou
wrote:
i wouldn't worry about that js performance and i do believe that the
current is the
correct default behavior but i do understand that this change breaks
existing running apps.
I see three options:
- bring the ids back (framework chan
> Here are the ones I know of right now:
> 1. Necessary changes for all applications
> - Page classes with instance variables that are not thread safe must
> be created in a method rather than declared. For example, creating an
> instance variable "private final DateFormat format =
> DateFormat.get
i wouldn't worry about that js performance and i do believe that the
current is the
correct default behavior but i do understand that this change breaks
existing running apps.
I see three options:
- bring the ids back (framework change)
- implement some kind of postprocessor that adds an id to all
Thinking about this some more... you could contribute a mixin to render an id,
of course, but that's time consuming and has problems if you're relying on, eg,
generated forms via bean editor and the like.
However... (and you've probably already thought of this, but...) you should be
able to rest
There's been a few backwards-incompatible changes from 5.1 to 5.2, I
think it would be helpful to have a place where these are documented.
Since you can't edit the wiki until you sign and mail/fax/scan & email
a license agreement, we can document them here and let someone with
access make the wiki
That's all true, and well. Except. We have apps out "in the wild" that rely
on the id being generated.
As for - to _ in identifiers, I don't remember the exact issue, but there's a
jira for it and it has to do with invalid identifiers, or the - in names
causing problems in some circumstances
Thanks for the reply Andreas,
I wouldn't call it redundant myself, that expression is not anywhere near as
efficient as finding the tag in the dom using an id.
> -Original Message-
> From: andre...@gmail.com [mailto:andre...@gmail.com] On Behalf Of
> Andreas Andreou
> Sent: 17 December
It makes sense to me to not output redundant html
And if you know the id of the control you can get to its label by
$$('label[for=' + id + ']')
On Fri, Dec 17, 2010 at 18:35, Blower, Andy wrote:
> The change was made in July and doesn't appear to be associated with a JIRA:
>
> r931361 | hlshi
The change was made in July and doesn't appear to be associated with a JIRA:
r931361 | hlship | 2010-04-07 00:01:00 BST
Do not render an id attribute for Label components, as they can be identified
via their for attribute
Yes they can, but it's pretty standard to find tags in the dom via id's,
Yeah... you can do that... I'm just not sure if those services are proxied. I
will definitely be curious to hear if it works... keep me posted. :)
Robert
On Dec 17, 2010, at 12/177:45 AM , Michael Gentry wrote:
> Well, I've used services without an interface before, so maybe it'll
> work, altho
On Fri, 17 Dec 2010 12:42:14 -0200, Stephan Windmüller
wrote:
You have to define the layout of the cell by yourself. Have a look at
http://tapestry.apache.org/tapestry5/tapestry-core/ref/org/apache/tapestry5/corelib/components/Grid.html
You can also provide a view block for your own types:
Great!
I was waiting the release to try it out 5.2 :)
Congrats for the great job
___
Everton Agner Ramos
2010/12/17 antalk
>
> Congrats on the new release, i hope to port our 2 existing webapps soon !
> --
> View this message in context:
> http://tapestry.1045711.n5.nabbl
Congrats on the new release, i hope to port our 2 existing webapps soon !
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Tapestry-Central-Announcing-Tapestry-5-2-tp3308716p3309558.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---
On 17.12.2010 15:22, Gunnar Eketrapp wrote:
> I just started to use the grid component and noticed that all fields that
> have a type other then standrad java types gets silently ignored.
>
> Can I add something to get them displayed or do I have create display
> classes with simpler value types
Hi!
I just started to use the grid component and noticed that all fields that
have a type other then standrad java types gets silently ignored.
Can I add something to get them displayed or do I have create display
classes with simpler value types for each grid !?
Yea yea I am reading the gr
Well, I've used services without an interface before, so maybe it'll
work, although I suspect it won't. I'll give it a try in a few days.
:-)
Thanks Robert!
mrg
On Fri, Dec 17, 2010 at 1:48 AM, Robert Zeigler wrote:
> Not sure that the DataObjects will work... the live service class reloading
Wow. Thank you very much.
Indeed, as I upgraded to 5.2 a couple of days ago I'm pleased to see
I've been running your final stable release.
I see the Wikipedia page has had a clean sweep - perhaps controversially
removing references to earlier versions. Mmmm - they must have been
disappeared to
Congratulations!
We were just discusing here at work to rewrite our main web application from
JSP to T5. I wanted to send some useful links to my coworkers for them to
start reading about T5. I stumbled upon
http://tapestry.apache.org/introduction.html which needs to be updated - the
text must be
37 matches
Mail list logo
