Jonathan Carlson wrote:
Eelco,
Your approach to the BeanPanel is pretty similar to mine, but instead
of using BeanInfo objects, I allow the developer to specify the
attributes and give them a little more control over how the HTML looks
(size of the text field, text area, etc). Will it be possible to
specify attributes that should be populated from a DropDownChoice box or
will the BeanInfo approach make that too difficult? If it's too
difficult then I should probably stick with my approach, although I'd
rather pool our efforts and help you out.
My gut feel (although I'd be happy if I am wrong) is that the BeanInfo
approach might be good for data administration apps, but not for apps
where you want more control over the look of the editing panel. Please
do tell me I'm wrong (if I am, that is :-). Using a preconfigured
component is always going to demand some trade-offs in flexibility so
I'm just talking about degrees of flexibility here.
Yes, the BeanPanel is the least flexible here, and I was actually
referening to the FieldsPanel. The FieldPanel is much more flexible; I
think we have the same goals for flexiblity.
As my example is by far from done, it misses flexibilities like the
field length. But a property like field lenght only makes sense for
Strings, which is the reason I deffered it from having it as a property
on Field. I'm still thinking about what to de here, but I am currently
thinking about just keeping a Map of attributes in Field for this.
I tried to stay close to a javabean-like pattern (xxxEditor naming
schema)
I'm not familiar with the xxxEditor naming schema you talk about. If
you have a link, I'd appreciate it.
Read all about JavaBeans here:
http://java.sun.com/j2se/1.3/docs/api/java/beans/package-summary.html
The pattern that I am refering to is the way BeanInfo works. When you
have a bean class, say 'MyBean', and in that same package you put
'MyBeanBeanInfo' (thus xxxBeanInfo) which has to implement BeanInfo,
that class is automatically discovered as the meta data class for
'MyBean' by the JavaBeans framework.
I also would like to make it less flexible; currently
you can feed it pull models, which is not such a good idea with so
much
going on.
When you talk about "pull models", are you referring to models that get
data from the database (for example?)
No, I mean the fact that I currently support IModel instances at all.
IModels are great for flexibility, but as you can provide any
implementation you want, including an implementation the e.g. returns a
different object every time, supporting IModel has the disadvantage that
you can't really cache/ keep state based on the last invocation. More
concrete: we generally want to analyze a bean once, and create a
subfields etc based on that, and cache what we have. That would make a
robust edit panel.
What I really mean with 'pull models', are those models that, instead of
keeping the model value as a in instance value, 'pull' its model values
from somewhere else, like from a database, but also just from another
method. The ability to work with pull models is great in Wicket, as it
allows you to do very advanced stuff. The downside is however, is that
you must be aware that these values can differ over time without prior
notication. I guess it is comparable with using setVisble and overriding
getVisible. While the latter allows using nifty algoritms, it also
prevents Wicket from detecting it's changes.
So, here's my point. I think it is a better idea to provide our bean
edit panels with just bean instances, which would be an immutable field
on the edit panel, so that we can analyze the bean in our constructor,
and create all the subcomponents needed without having to worry about
pull issues.
I haven't seen any articles on what the new JavaBean spec is going to
look like. If you see any, please let me know.
Sure. There is work going on on the new JavaBean specification, JSR 273
(http://www.jcp.org/en/jsr/detail?id=273), which also kind of merges the
concept of PropertyEditors and Customizers and will try to resolve some
of the problems with the current spec. Good news is that one of our core
members (Jan) will probably participate in that JSR.
- Jonathan
Eelco
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
