Ok, it works in the way you recommend. Thanks.
The last question :
for ajax request, we can write
a:actionParam value=#{row.id} assignTo=#{testBean.id}
- no need to specify param tag in pages.xml - right ?
There is no assignTo in f:param, though..
View the original post :
Yes, but this doesn't give you parameter propagation of course.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4115349#4115349
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4115349
As it says in the seam reference:The param declaration is bidirectional
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4115174#4115174
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4115174
[EMAIL PROTECTED] wrote : You don't need to use @RequestParamater with page
parameters. Take a look at seamdiscs to see how they should be used.
I see no param tags in pages.xml of seamDISKS example (Seam 2.0) .
In seamSPACE , I see the following :
pages.xml :
page view-id=/comment.xhtml
damianharvey,
thank you for the example.
This radically differs from the model I have had in mind about page parameters.
I thought that tag
param name=id value=#{testBean.id}/
takes value FROM #{testBean.id} and makes it available via @RequestParam.
In your example, value is being taken
I don't think that there's anything *wrong* with @RequestParameter, but it
isn't optional so your Bean containing it must always be passed it.
Using just page params is just as easy. You would do something like this:
test.xhtml:
| a4j:outputPanel id=testPanel
| h:dataTable
|
No one have delete controls in data tables :) ?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4114566#4114566
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4114566
___
jboss-user
This is a problem with using the @DataModelSelection approach. If you used page
parameters you wouldn't have this problem as you would be deleting rows by id
rather than position in a list. So I would use page parameters ;)
View the original post :
Oh dear. So all my hard work removing IDs from my application is wasted?
Exposing IDs in my app is a bit of an issue.
Do you know if it is just @DataModelSelection that is the problem or @DataModel
in general? Ie. if I use this:s:link
action=#{myBean.delete(myObject)}...will I still face this
[EMAIL PROTECTED] wrote : If you used page parameters you wouldn't have this
problem
Thank you!
Does any Seam examples project illustrate this recommended approach ?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4114598#4114598
Reply to the post :
damianharvey wrote : Oh dear. So all my hard work removing IDs from my
application is wasted? Exposing IDs in my app is a bit of an issue.
Sure, there are some apps where page parameters aren't appropriate.
We need to dig into exactly what works and doesn't with passing parameters to
EL action
I originally removed the IDs as I didn't want the user hacking around trying to
find someone else's data. It's the usual use-case I suppose and certainly
something that I do whenever I see IDs in the query string. I can check the
authorisation of the user in the find() or similar but the
Not removing @DataModel, just removing the ability to pass objects inside of
iterations using extended EL. The ability to pass an ID would still be there of
course, but that doesn't meet your obfuscation requirements (which I agree with
on a conceptual level). However, there is both Gavin's
[EMAIL PROTECTED] wrote : If you used page parameters you wouldn't have this
problem as you would be deleting rows by id rather than position in a list. So
I would use page parameters ;)
I have solved problem partially with page parameters, but it does not work for
ajax request (used exactly
You don't need to use @RequestParamater with page parameters. Take a look at
seamdiscs to see how they should be used.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4114701#4114701
Reply to the post :
I tried to recreate your issue but if I attempt this, Hibernate throws a
anonymous wrote : org.hibernate.StaleStateException : Batch update returned
unexpected row count from update [0]; actual row count: 0; expected: 1
I'm glad you raised this though as I'll make sure I handle this error. Not
damianharvey wrote : How do you do your delete? Something like
this?myList.remove(selectedObject);
| | entityManager.remove(selectedObject)
|
Not quite. First operator myList.remove(selectedObject) is the same.
What comes to second : my list of records is actually a collection of entity
17 matches
Mail list logo
