While I'm at it, there's another thing that confuses me.
If I login, I select a space (that I'm member of), and a LR conversation is
started that keeps track of my do's and don'ts in that space. However, if I'm
an admin of that space, I can click the "edit" button that takes me to the page
wher
omg, I think I found the problem...
For clarity, I omitted this section in the second form-entry:
|
| #{messages['noMembersPresent']}
|
|
so the second entry actually is:
|
|
| company
|
|
|
|
|
"[EMAIL PROTECTED]" wrote : "hstang" wrote : I played around with JSF
validation for a few days, and I just couldn't get it play nicely with Seam. I
ran into some bizarre problems with transaction management and I just said
forget it--I resorted to just action-validation instead.
| | I don'
Ok, lets see the backing bean as well :)
You are using a form of JSF validation (#{spaceManager.validateSpaceName}), but
you aren't using what Gavin is calling JSF (I would perhaps call it
Seam/Hibernate/JSF validation ;) ) - Seam/JSF/Hibernate validation is using a
combination of @Min, @Max et
Hi Gavin, here's my code without the templates:
|
|
|
| name
|
|
|
|
|
| company
|
|
|
|
"hstang" wrote : I played around with JSF validation for a few days, and I just
couldn't get it play nicely with Seam. I ran into some bizarre problems with
transaction management and I just said forget it--I resorted to just
action-validation instead.
|
| "beligum" wrote :
| | Gavin,
I played around with JSF validation for a few days, and I just couldn't get it
play nicely with Seam. I ran into some bizarre problems with transaction
management and I just said forget it--I resorted to just action-validation
instead.
"beligum" wrote :
| Gavin, I don't actually use Seam va
BTW, when you say "the changes are persisted", how do you determine this? By
looking in the database?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052925#4052925
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052925
Well, I don't see any JSF validators in the code you have posted either
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052924#4052924
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052924
___
I'm getting strange behaviour, and my guess is it's caused because of my
misunderstanding of conversations (yes, I've read through the entire manual and
many other docs too :-).
I'll try to explain my 'workflow' in my own words, maybe I'm thinking wrong.
I log in (almost default authenticator)
I tried to extract the functionality from my app and created a simple example
out of it, just like Peter suggested.
Seems like all is well there. Validation occurs, and transaction rollback
happens when an exception is thrown or the @Rollback is triggered.
Apparently, I'm doing something wrong el
Um, where is your s:validate or s:validateAll??
I don't think you're doing any JSF validation at all! All you are getting is
validators running when Hibernate tries to write to the database! (Hence the tx
rollback.)
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopi
I think we still have some confusion here: JSF does
1) RESTORE VIEW
2) APPLY REQUEST VALUES (update the JSF component instances with the submitted
values - localValue on EditableValueHolder) (no affect on your backing beans
here)
3) PROCESS VALIDATIONS - run converters, then validators (this is
Hi again.
I've done some debugging and found interesting results.
In my update-form, I have these input-controls (they're templated, but you get
the point)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Thanks for your replies guys, you cleared out some confusing matter to me.
The quality of the community-helpdesk around Seam is most certainly one of the
reasons it's adoption-rate is elevating so quickly.
I'll try to share my findings with other people, once I've catched up with some
deeper stuf
Sorry about truncating my reply, I had to go out.
"beligum" wrote : 5. Is it normal I can't use if I use
@PersistenceContext instead of an injected (@In) entity manager?
Yes. s:convertEntity uses an SMPC / Seam managed transactions to reload the
entity from the PC. Unless you have a LRC in w
"beligum" wrote : 0. If I inject (@In) my EntityManager in Seam, it holds an
extended persistence context, right?
If there is a long-running conversation, yes.
"beligum" wrote : 1. If I call merge() or not in the update() method, it
doesn't make any difference, the changes are always written to
Hi guys, thanks for the replies, this is great stuff.
Any chance anyone wants to explain what happens if a RuntimeException is thrown
in my update() method? This is the only major conceptual hurdle I'm still
struggling with. My common sense tells me, when that method 'fails', the update
model v
"beligum" wrote : Hi all,
| 6. Is there a way to specify flushMode=MANUAL in the
tag of pages.xml?
|
Yes-- just specify flush-mode="MANUAL"
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052844#4052844
Reply to the post :
http://www.jboss.com/index.ht
"beligum" wrote : 0. If I inject (@In) my EntityManager in Seam, it holds an
extended persistence context, right?
A persistence context scoped to (current) conversation will be injected. An
extended persistence context is only scoped to the current SFSB whilst SMPC
allows *any* bean participat
20 matches
Mail list logo
