Mike Snare wrote:
>The only problems with client persistence are that
> 1) the object has to be serializeable
> 2) it increases the size of the page
> 3) URLs get long, since the object has to be sent back and forth.
>
>A possible alternative might be tapestry-flash
>(http://howardlewisship.
Don't know, but I imagine it leaves the session up.
On 3/29/06, Adam Zimowski <[EMAIL PROTECTED]> wrote:
> So I checked it out... This may be of use to me :-)
>
> Question: so once the object is done (ie flashed), will this
> invalidate/destroy the session if it had to create one? I would be
> int
So I checked it out... This may be of use to me :-)
Question: so once the object is done (ie flashed), will this
invalidate/destroy the session if it had to create one? I would be
interested in something like this because my app avoids creating a
session under "guest" user at all possible costs. I
The only problems with client persistence are that
1) the object has to be serializeable
2) it increases the size of the page
3) URLs get long, since the object has to be sent back and forth.
A possible alternative might be tapestry-flash
(http://howardlewisship.com/tapestry-javaforge/tap
Try client persistance.
persist="client:page" instead of persist="session"
GbT wrote:
> Ok, I understand, but it seems code redundant for me to write three
> property for the same object only to submit values back... Suppose I
> have 20 fields for example to edit... I have to declare every sing
Ok, I understand, but it seems code redundant for me to write three
property for the same object only to submit values back... Suppose I
have 20 fields for example to edit... I have to declare every single
field in the Edit page... and assign every form field to them
Isn't it possible t
The problem with just making it persistent is that you now have to
handle the case where the user gets to the edit page via a path other
than the intended one (probably clicking on an article title or
something).
Normally, you could just check to whether the article or id was null
or empty in the
I resolved making the property article persistent for the session in
the articleEdit page, now it works perfectly.
Anyway I'll try as you suggested if it's a better solution.
Thanks
Il giorno 29/mar/06, alle ore 14:37, Mike Snare ha scritto:
Ok. When you give the edit page an article, You'r
Ok. When you give the edit page an article, You're doing it basically
so you can pre-load the article title and content on the edit page,
right? That works, but when you submit it, what you're actually
trying to set are the values of EditPage.article.title, etc. The
problem is that the article o
Hmmm it isn't working ... I inject the ArticleList page and tried
with your suggestion but the error is still here:
Unable to update OGNL expression '' of
[EMAIL PROTECTED] to aaa: target is null for
setProperty(null, "body", aaa)
It's very strange because my article is set before
Assuming that you are injecting the ArticleEditPage, try:
ArticleEdit ap = getArticleEditPage();
ap.setArticle(a);
return ap;
I don't think the call to getArticleEditPage() is guaranteed to return
the same instance every time if it's injected. Thus your 2 calls to
it return 2 different objects.
I'm trying to edit an article object from a list of article
objects... when I click on the article link to edit I call this method:
public ArticleEdit editArticle(Integer pk) {
Article a = (Article)DataObjectUtils.objectForPK(getSession
().getDataContext(), Article.class, pk);
12 matches
Mail list logo
