I have used IGx89's converter and it is working perfectly for me
I've made a few slight changes but nothing major... other then that I have
moved the Store outside the converter.
Oh and I have done some specific stuff for my project to make it easier for me
but you can get rid of all that.
I have a selectOneMenu where selectItems come from a WebService which returns a
collection of a simple POJO class.It has an identifier,and some fields,but
since it is not managed by any EntityManager or HibernateSession I can not use
s:convertEntity. I think this is the case you didn't come
Have you tried my ObjectConverter?
Another potential solution (if you don't want to use ObjectConverter) is to use
the new itemValue attribute on s:selectItems that'll be in Seam 2.0.1.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4106827#4106827
Reply to
It has Event scope by default. It should (maybe) have stateless scope by
default, I'm still not sure.
I guess making the converter page scope and not separating them should work,
but I've never tried (I'm not sure how this will interact with JSF's state
saving).
View the original post :
*bump*
From the recent posts in
http://www.jboss.com/index.html?module=bbop=viewtopict=122653, it would seem
that while Converter has an Event/Page scope (which one? code says former, but
my observations show latter), you plan in the future to force it to have a
Stateless scope? If that's the
So far I've yet to run across any problems, though I've just been using it for
selectOneItem's and am using server-side state saving with no clustering.
Testers would be nice...
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4100698#4100698
Reply to the post :
Pete, why do they need to be separate? @Create's being called only once per
page and everything seems to work fine. Changing the scope doesn't seem to
work, but that doesn't seem to affect anything negatively in this case.
View the original post :
Look at the EntityConverterStore.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4099641#4099641
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4099641
___
jboss-user mailing list
Ok, I've tried using IGx89's converter but moving the store outside of the
converter. And it *almost* works!
I'm running into a small problem though.
My code is as follows:
ObjectConverter.java
| package gekko.web.converter;
|
| import static org.jboss.seam.ScopeType.CONVERSATION;
|
I think you need to separate out the converter and the store. This way Seam
manages the scope of the store, whilst the converter is handled by JSF.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4099570#4099570
Reply to the post :
Well guys, thanks for all the input.
I didn't really know any other way to solve my problem so the converter is it
for now I guess.
@IGx89
I'll try your code when I get back to work and see if it works.
@[EMAIL PROTECTED]
How should the store be done pete? I'm really quite new to the seam
How's this look?
@Name(org.jboss.seam.ui.ObjectConverter)
| @Scope(PAGE)
| @Install
| @Converter(forClass=Object.class)
| @BypassInterceptors
| public class ObjectConverter implements javax.faces.convert.Converter,
Serializable {
|
| private MapString, Object objects;
|
|
(remove the forClass=Object.class from the @Converter annotation; remnant of
some experimentation)
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4099500#4099500
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4099500
Kragoth wrote : Infact maybe the Seam guys should implement a generic
converter for non Entity classes.
How do you propose we do that?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4098865#4098865
Reply to the post :
A page-scoped map of converter-generated GUID - object references? Seems
relatively easy on the surface; pretty much every UI framework I've worked with
has support for doing that (using client-side or server-side state saving).
Though it must not be that easy with JSF, because otherwise I'm
Feel like writing a patch? :)
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4098897#4098897
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4098897
___
jboss-user mailing list
It'd be a new converter and not a patch, right? I'm still hesitant, since if it
really is as easy as it seems then it makes no sense why you'd have gone
through all the trouble of writing the Entity converter...
View the original post :
I vote -1 on that, unless my mind can be changed on it, but it seems that
everything needed can either be an an enum, an entity, or a String. I just
don't see regular undefined pojos needed in a select case.
View the original post :
Kragoth,
Stateful beans hold state. Stateless will not hold, or guarantee to hold member
variable data when you leave it. So if you are selecting data from a bean and
hope to come back to that same instance it needs to be stateful.
But now you forced me to ask a question. ;) Gonna make it
What if you want a datagrid with info from entity fields along with checkboxes
for some UI task? You obviously don't want to add a boolean field to the entity
class for a purely UI feature, so you'll need to create a POJO wrapping the
entity and adding the boolean field...
View the original
Forgot to specify that the stateful is intended for EJB3 database stateful
conversation. So if you don't use EJB3 (which it looks like you don't) you
will not need it. (Verification would be good from others).
View the original post :
1) I never came across a use case in the wild that, as Dan says, wasn't either
an entity or supported by a built in JSF converter (your example is covered by
javax.faces.Boolean)
2) You can't convert entities like that as JSF may serialize page scoped
variables (when using client-side state
oops. Of course, you mean with a boolean field added. Well in this case my (2)
applies. So there is no easy way to write a generic converter in this case
short of caching the objects in session scope.
But, I'm open to ideas (I did the initial work on this for Seam 1.1 or
something and the
Ok, #2 would definitely explain why there's an EntityConverter and not an
ObjectConverter.
It seems there are, at the very least, three ways to approach this:
1. Do what I originally suggested (an ObjectConverter that serializes to the
page scope), requiring objects to not be (or contain!)
1 2 are not mutually exclusive (just be clever and warn if an invalid
combination comes up)
3 is not a viable option as it is basically a memory leak
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4099043#4099043
Reply to the post :
How hard/expensive would it be to determine if an object is or contains any
entity classes? For simple POJO's I'd imagine it'd be pretty simple, but once
you get into nesting or collections or stuff I imagine it'd be much more
complex? Or is there a method in Seam which makes that all a piece
It's relatively easy to determine if an object is an entity through
PersistenceProvider (if its not, it can be added). I can't see why you would
worry about whether it contains a collection of entities.
View the original post :
So while it's not fine to put an entity into a client-side state, putting an
object wrapping the entity into there is fine? But would't the entity be
serialized in either case? I guess I'm just a little confused on how that all
works. However, I'm fine with just taking your word for it :).
1. Is there more to your stack trace?
2. What version are you using?
3. Your bean is not stateful, intentional?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4098638#4098638
Reply to the post :
1
No stack trace is given. The error message is from a h:messages component.
2
Seam 2.0.0CR2
JSF 1.2
3
I'm not entirely sure what I need to do regards Stateful / Stateless for this
bean.
Another slightly smaller issue is that it does not select the no Selection
item as default. I would like
Ok, I've made progress!!!
If I remove the @DataModelSelection annotation everything works exactly the way
I want it.
Hopefully someone else gets some good out of this code!
Infact maybe the Seam guys should implement a generic converter for non Entity
classes.
View the original post :
31 matches
Mail list logo
