On Mon, 26 Nov 2012 18:45:14 -0200, Pillar sotodel...@hotmail.com wrote:
Hi,
Hi!
In the Tapestry User Guide for session storage
http://tapestry.apache.org/session-storage.html , it states Any other
component or page that declares a field of the same type, regardless of
name, and marks it
: Re: SessionState
On Mon, 26 Nov 2012 18:45:14 -0200, Pillar [hidden email] wrote:
Hi,
Hi!
In the Tapestry User Guide for session storage
http://tapestry.apache.org/session-storage.html , it states Any other
component or page that declares a field of the same type
On Mon, 26 Nov 2012 19:17:45 -0200, Pillar sotodel...@hotmail.com wrote:
I don't know if it's common practice to send thank you's in a mailing
list, but screw it. Thanks! I'm pretty sure I'll be using much more of
Tapestry in the future.
We in the Tapestry mailing lists are very happy to
On Fri, 30 Mar 2012 03:44:33 -0300, resign sergejb...@yahoo.de wrote:
hi,
Hi!
is it possible to add an translator to textfield depends on logged user?
For example i want to translate Date object depends on logged user.
Use the translate parameter of TextField.
--
Thiago H. de Paula
I think I found where causes the problem.
Here is the tml file:
t:grid source=AllSales exclude=unitPriceNumber, vatNumber, totalNumber,
id row=salesItem add=action reorder= sku, desc, qty, freetext,
returnorsale, unitprice, vat, total
p:skuCell
t:actionlink t:id=edit
On Wed, 05 Oct 2011 17:56:44 -0300, leothelion okram...@hotmail.com
wrote:
If I erase the ' row=salesItem ', then the adding problem is gone. But
I cannot use a SessionState instance as a row in grid component?
Yeah, but it's not a good idea, as you're using the same field for two
very
Hi Thiago,
Thanks for your reply. I will try it.
Just a question out of this topic. I use salesItem as SessionState is
because I don't what it to be shared by the other users when they are
loading the same page. That's why I came up with the idea of SessionState. I
don't know if there another
Tapestry objects's instance variables will never leak from user to user..
You have to try pretty hard to make that work.
Whether its' @Persist, @SessionState, @SessinoAttribute,
or just plain field, it will never leak.
On Oct 5, 2011, at 5:22 PM, leothelion wrote:
Hi Thiago,
Thanks for your
On Wed, 05 Oct 2011 19:00:05 -0300, okramlee okram...@hotmail.com wrote:
Hi Thiago,
Hi!
If a field isn't @SessionState, it is completely thread-safe, not
being shared between users.
Yeah, that was what I thought about. But it did share the object between
users even though I remove
If you did private SalesItem salesItem = new SalesItem()
You got me!!!:-P
Thank you very much.
On 10/5/2011 3:12 PM, Thiago H de Paula Figueiredo [via Tapestry] wrote:
On Wed, 05 Oct 2011 19:00:05 -0300, okramlee [hidden email]
/user/SendEmail.jtp?type=nodenode=4874465i=0 wrote:
Hi Thiago,
I'm replying to this somewhat old thread just to say that I have found
the problem.
The problem was that I had stored something as a SessionState Object
(SSO), then I forwarded the user to another website to do some
authentication which forwarded the user back to my site. But when the
user
Ha! Good catch, and annoying.
For anyone who hasn't addressed this, when I'm in apache fronted
tomcat I use a rewrite rule in apache to make sure everything goes to
the www. url...
I suppose you could also do the same thing in a Tapestry request filter.
Josh
On Wed, Jun 29, 2011 at 9:35 AM,
On Wed, 29 Jun 2011 15:20:48 -0300, Josh Canfield joshcanfi...@gmail.com
wrote:
Ha! Good catch, and annoying.
For anyone who hasn't addressed this, when I'm in apache fronted
tomcat I use a rewrite rule in apache to make sure everything goes to
the www. url...
I suppose you could also do the
http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry5/annotations/SessionState.html
Specifically:
public abstract boolean create
If true (the default), then referencing an field marked with the
annotation will create the SSO. If false, then accessing the field
will not create the
Thanks Josh (and Thiago).
I added (create = false), and this certainly got rid of the error message.
However, my session object is still either not getting set correctly
(even though I clearly visit the page where it gets set, and I even
write a message to the log saying I was there), or it
On Wed, 11 May 2011 15:17:42 -0300, Tim Koop t...@timkoop.com wrote:
Thanks Josh (and Thiago).
You're welcome!
I added (create = false), and this certainly got rid of the error
message. However, my session object is still either not getting set
correctly (even though I clearly visit the
Are you sure you're getting the same session when you come back to the
page? try dumping the session id.
@Inject
private HttpServletRequest request;
void onActivate() {
final HttpSession session = request.getSession(false);
log.debug(session == null ? Null session :
I'm trying to authenticate on my website with OpenID, using Java code
from the openid4java library.
After the user specifies his OpenID provider, the server (Tapestry) is
supposed to forward him to the appropriate web page (like Google) to get
authenticated, then it forwards the user back to
On Wed, 11 May 2011 15:35:15 -0300, Tim Koop t...@timkoop.com wrote:
I'm trying to authenticate on my website with OpenID, using Java code
from the openid4java library.
After the user specifies his OpenID provider, the server (Tapestry) is
supposed to forward him to the appropriate web page
Well, I just tried checking the session id like this, and it is in fact
the same after coming back. And the SessionState objects started
working too!
So then I took out this session id code, and the SessionState objects
are still working.
So now it's all working fine, and I am left
Hi everybody,
To partially address the concerns raised, and following Pierce's
suggestion (and using many of his words), I have updated this page in
the User Guide to help make it clearer what the pitfalls and decision
points are for using @SessionState and @SessionAttribute:
Your two lists are the same - they're both of type List so they both get
assigned to the same thing. See below for why.
The solution is to make two classes, one that holds the booleans, and one
that holds the strings. Technically you would only need to do that for one,
but it's probably a good
Tapestry will treat the two as the exact same SessionState since they both
are java.util.List - the Boolean/String type parameters will not help
differentiate between the two.
It is possible to get around this by changing one of them to
Collection/Iterable/ArrayList/etc so that they use two
Hi Donny,
Thanks for the explanation, but the types might be a red herring. I'm
less concerned about that than the fact that Tapestry seems to be
assigning one of my variables to a different variable. It doesn't
matter if the types are the same or different. I could've had:
The reason why they're both considered the same: this has to do with how
generics work in Java.
I'm building in better generics support for 5.3, this seems like something I
can make work. All of the generic information is available for fields,
methods, and method parameters via reflection.
On Thu, 06 Jan 2011 13:09:43 -0200, Michael Gentry mgen...@masslight.net
wrote:
Hi Donny,
Hi!
Thanks for the explanation, but the types might be a red herring. I'm
less concerned about that than the fact that Tapestry seems to be
assigning one of my variables to a different variable. It
Ah that's the problem then. You're expecting them to be assigned based on
the name of the variable, but @SessionState assigns them based on their
type.
You could have in page1:
@SessionState
private String username;
In page 2:
@SessionState
private String email;
And they would be assigned to
On Thu, 06 Jan 2011 13:14:09 -0200, Josh Canfield joshcanfi...@gmail.com
wrote:
Next on my list is generic services (@Inject GenericDAOPerson
personDao;) it's implemented but working through tests/use cases. I'll
add @Persist.
Shouldn't it be @SessionState? ;)
--
Thiago H. de Paula
yeah, typing too fast, kids running around my legs getting into stuff! :)
On Thu, Jan 6, 2011 at 7:17 AM, Thiago H. de Paula Figueiredo
thiag...@gmail.com wrote:
On Thu, 06 Jan 2011 13:14:09 -0200, Josh Canfield joshcanfi...@gmail.com
wrote:
Next on my list is generic services (@Inject
Thanks for the explanation, but the types might be a red herring. I'm
less concerned about that than the fact that Tapestry seems to be
assigning one of my variables to a different variable.
You did assign them to the same thing, you just didn't know it. You
told tapestry to store the value
On Thu, Jan 6, 2011 at 10:14 AM, Thiago H. de Paula Figueiredo
thiag...@gmail.com wrote:
On Thu, 06 Jan 2011 13:09:43 -0200, Michael Gentry mgen...@masslight.net
Thanks for the explanation, but the types might be a red herring. I'm
less concerned about that than the fact that Tapestry seems to
- original Nachricht
Betreff: Re: @SessionState Bug?
Gesendet: Do, 06. Jan 2011
Von: Donny Nadolnydonny.nado...@gmail.com
Ah that's the problem then. You're expecting them to be assigned based on
the name of the variable, but @SessionState assigns them based on their
type.
You could
Hi Mike,
I understand that the behavior seems a bit non-intuitive. It has to do with
the fact that the @SessionState objects are global (ie not per-page) objects.
The decision was made early on to base these solely on the type of the object,
rather than on the name of the object.
Usually,
?
Component1
@SessionState
private String eMailAddress;
Component2
@SessionState
private EmailAddress emailAddress;
regards nillehammer
- original Nachricht
Betreff: Re: @SessionState Bug?
Gesendet: Do, 06. Jan 2011
Von: Donny Nadolnydonny.nado...@gmail.com
Ah that's
if you were able to maintain that.
What would you expect Tapestry to do in the following case?
Component1
@SessionState
private String eMailAddress;
Component2
@SessionState
private EmailAddress emailAddress;
regards nillehammer
- original Nachricht
Betreff: Re
Hi Robert,
I understand what it is doing now, but still find it non-intuitive. I
think part of this goes back to the whole POJO subclasses-are-evil
debate. In my use case, I had an abstract wizard page that had a lot
of concrete subclasses that needed to share data on multiple pages
(@Persist
On Thu, 06 Jan 2011 14:42:09 -0200, Donny Nadolny
donny.nado...@gmail.com wrote:
Hi Nille,
Hi, guys!
I don't think it's the only way to do it. Determining it based on the
variable name (or maybe name/type pair) would work. It would just have a
different set of problems.
Don't forget
@SessionState
private EmailAddress emailAddress;
regards nillehammer
- original Nachricht
Betreff: Re: @SessionState Bug?
Gesendet: Do, 06. Jan 2011
Von: Donny Nadolnydonny.nado...@gmail.com
Ah that's the problem then. You're expecting them to be assigned based on
the name
Hi Thiago,
Absolutely, I agree - @SessionState can't be changed to be based on name. I
was just arguing that handling session state based on name is an alternate
solution, just they both solutions have a set of problems.
On Thu, Jan 6, 2011 at 11:53 AM, Thiago H. de Paula Figueiredo
On Thu, Jan 6, 2011 at 11:56 AM, Josh Canfield joshcanfi...@gmail.com wrote:
In 5.2 there is SessionAttribute which pulls the value from the
session by name, defaulting to the name of the field...
Hi Josh,
SessionAttribute sounds much more promising to me. Thanks for the tip!
mrg
On Thu, 06 Jan 2011 14:56:00 -0200, Josh Canfield joshcanfi...@gmail.com
wrote:
In 5.2 there is SessionAttribute which pulls the value from the
session by name, defaulting to the name of the field...
Ooops, I missed that. Thanks Josh!
--
Thiago H. de Paula Figueiredo
Independent Java,
On Thu, Jan 6, 2011 at 11:56 AM, Josh Canfield joshcanfi...@gmail.com wrote:
In 5.2 there is SessionAttribute which pulls the value from the
session by name, defaulting to the name of the field...
Hi Josh,
@SessionAttribute is working great so far. Thanks again for the tip.
For discussion by
You could still have the problem of someone using @SessionAttribute and
giving the variable the same name as some other session variable.
I might take it one step further - declare a single class/enum with the
names of all of your session variables, and *always* use the name parameter
for
Michael,
@SessionState will not be deprecated. I guess you are missing the use case
for this very useful annotation. Some examples are a logged in user or a
shopping basket. Usually you have only one instance of such an object in
your app, so it is absolutely fine to same only one instance per
On Thu, 06 Jan 2011 17:21:32 -0200, Michael Gentry mgen...@masslight.net
wrote:
I'd like to suggest that @SessionState be deprecated in favor of
@SessionAttribute in the future.
I'm completely against. @SessionState has been used as it is since Tapetry
5 exists. I think @SessionAttribute
Hi Donny,
I will always use the name attribute.
Thanks,
mrg
On Thu, Jan 6, 2011 at 2:40 PM, Donny Nadolny donny.nado...@gmail.com wrote:
You could still have the problem of someone using @SessionAttribute and
giving the variable the same name as some other session variable.
I might take
Hi Igor,
How am I missing the use case of doing something like:
@SessionAttribute(value=Constants.USER)
private User user;
or
@SessionAttribute(value=Constants.SHOPPING_CART)
private ListShoppingCartItem shoppingCartItems;
This does everything that @SessionState does, but gives you more
Hi Thiago,
You argue that @SessionState is type-safe, but it is data-dangerous.
Is that a good trade-off? I personally want my data to be safe, too.
:-)
Also, If I do:
@SessionAttribute(user)
private String user;
On something that was already set to be a User record (instead of a
string),
I'm with Igor. :) I've never used @SessionState for simple object types
(List, Boolean, String, and the like). I've only ever used it for composite
object types that will only ever have a single object per session (Visit,
ShoppingCart, User, and that ilk). For that matter, in practice, I
Hi!
As I said, in this case, what you consider dangerous I consider safe and
vice-versa. Just different opinions. :) I agree that there's no completely
safe option. Both have their pros and cons. And I don't consider
@SessionState data-dangerous at all. I'd never use non-specific object
Hi Thiago,
I meant to mention that I don't consider @SessionState has been used
as it is since Tapetry 5 exists. to be a very good reason/excuse
because @IncludeJavaScriptLibrary and @IncludeStylesheet are now
deprecated. Things sometimes change (and hopefully for the better).
:-)
Cheers,
mrg
On Thu, Jan 6, 2011 at 9:13 PM, Michael Gentry mgen...@masslight.netwrote:
Hi Igor,
This does everything that @SessionState does, but gives you more
control. Plus you can easily use a data type more than once.
Nope, with @SessionState you have auto-building of SSOs and co-called
On Thu, 06 Jan 2011 19:40:31 -0200, Michael Gentry mgen...@masslight.net
wrote:
Hi Thiago,
Hi, Michael!
I meant to mention that I don't consider @SessionState has been used
as it is since Tapetry 5 exists. to be a very good reason/excuse
because @IncludeJavaScriptLibrary and
I'm also opposed to deprecating @SessionState, for many of the reasons below.
Perhaps you could build a CYASessionStateWorker that looks at
@SessionState annotated fields and pukes if the type is outside of
some package you specify. For instance, all of my @SessionState
objects generally go in a
On Thu, 06 Jan 2011 21:38:15 -0200, Josh Canfield joshcanfi...@gmail.com
wrote:
Perhaps you could build a CYASessionStateWorker that looks at
@SessionState annotated fields and pukes if the type is outside of
some package you specify. For instance, all of my @SessionState
objects generally go
I'd like to suggest that @SessionState be deprecated in favor of
@SessionAttribute in the future.
Thoughts?
This is ultimately a _documentation_ error. (If we ignore the problem with
generics for the moment.)
That is, the real problem is that the docs for
I'm not sure if this is the recommended way, but I find it both easy and
self-descriptive to write wrapper classes for these java objects so you
can use either SessionState or the Environment to move them across pages
in the application. For example, if you have a String for the name of
the
I understand that @SessionState was meant for POJOs. What's the
preferred (if any) way in Tapestry to store Strings, Integers and such
across multiple pages?
It really depends on the use case. If you can bundle them up into a
class that'd be the best way. For instance, if you're storing some
I find it both easy and self-descriptive to write wrapper classes for these
java objects.
That's exactly what I'm trying to avoid. With a large team of junior
programmers this will be a maintenance nightmare.
You could always grab the HttpSession and store them yourself.
From my searching
Yes! I forgot about that. Works like a charm :)
On Tue, Sep 14, 2010 at 1:46 PM, Guerin Laurent lgue...@sopragroup.com wrote:
Hi,
From tapestry 5.2 you can use @SessionAttribute.
Envoyé de mon iPhone
Le 14 sept. 2010 à 20:34, Adam Zimowski zimowsk...@gmail.com a écrit :
I find it both
Em Mon, 01 Jun 2009 18:04:01 -0300, Thibaut Gadiolet
thibaut.gadio...@gmail.com escreveu:
Hi folks,
Hi!
@SessionState
private String userName;
Use @SessionState(create = false). This prevents Tapestry of trying to
instantiate a String when userName wasn't set yet.
--
Thiago
Thank you so much ! It works perfectly right now !
On Mon, Jun 1, 2009 at 5:06 PM, Thiago H. de Paula Figueiredo
thiag...@gmail.com wrote:
Em Mon, 01 Jun 2009 18:04:01 -0300, Thibaut Gadiolet
thibaut.gadio...@gmail.com escreveu:
Hi folks,
Hi!
@SessionState
private String
@SessionState is meant for data holding POJOs, not simple types.
On Mon, Jun 1, 2009 at 2:04 PM, Thibaut Gadiolet
thibaut.gadio...@gmail.com wrote:
Hi folks,
As soon as I put the annotation @SessionState in my application, I get an
error.
*here is a sample of code from home.java*
*
63 matches
Mail list logo
