JBossDeveloper

I'm looking forward to checking out the DataBinder support this evening. Cudos for getting this in prior to Seam 1.0 GA.

Gavin do you know of any plans for a JBoss hosted component repository for Seam? I would think that as Seam the framework takes off there will be many valuable components, data binders, and the like developed by the Open Source community. The reuse of these components could save massive time world wide.

I would also recommend that Seam ship with default data binders for the two JSF model objects that ship with Java EE 5. Developers new to Seam need to learn to use the framework before developing modules for it and it makes sense to be productive with the entire JSF RI rather than just DataModel.

Actually now that I think more about it it may be a better idea that Seam ship with no data binders and that a component repository containing these data binders and more be released along with 1.0 GA. This way you can separate the core framework from all the extensions.

-Jim

Of course once you start talking repo you need to think about a package structure. JAR + META-INF/*.xml feels right to me but that's just knee jerk.

-Jim

Is it possible to pass the annotation into all the DataBinder and DataSelector methods? I wrap based on attributes on my annotation and will also need to select based on attributes on the annotation.

Also, does Seam provide for any built in dirty checking, or are objects wrapped and unwrapped on every request by default?

I didn't want to try and have a conversation about dirty checking within JIRA...

What are your thoughts on dirty checking? Seam could keep track of field/method access and then simply not call the DataBinder methods if there haven't been any changes since the previous wrap/unwrap invocations.

Within wrap/unwrap the DataBinder could be forced to do it's own dirty checking based on information stored in a custom wrapped object (approach currently taken).

Seam could signal the DataBinder that it has observed access to the object and that it might be dirty (via additional param on wrap/unwrap?). Then the binder could take its own action as it wishes. wrap/unwrap would be called on each request.

-Jim

I see the CVS addition. And if isDirty() is true, Seam then doesn't call the wrap/unwrap methods?

I'd suggest that the annotation be passed through to this method as well. No telling what original information might be beneficial to DataBinder writers down the road.

For example, what if someone wanted to invalidate this object (or not) based on the state of another object? That information would need to be stored in the annotation.