On 8/25/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
Ah, missed this in the earlier post about styling, but perhaps it needs a new thread anyway. That style [1] does not process the className attribute of all the legal dialog config elements. The className attribute came in through SHALE-120 [2].
Essentially, this lets you customize the configuration objects that model the internals of the dialog. Sean had a particular use case that he can comment on ... but I imagine that this kind of thing would require the application to access and customize the SCXML configuration beans instead. What I don't know yet: * Is this possible/convenient? * Is this a good idea? From watching what people have done customizing the configuration beans of Struts 1.x, it has enabled adding a lot of power. But it sure feels like we're exposing an internal implementation detail. Craig Its basically an open door. Now I'm trying to make some sense of it
for the SCXML port. In the absence of className, we could be ready to try out using Commons SCXML for the dialog internals in about a week, possibly. In the longer run, it might be possible for most of the stuff in the dialog package [3] (and its child packages) to disappear after a regular deprecate / remove cycle if we (you ;-) decide to go the SCXML route. Not sure how to handle the className attribute, perhaps interim its best to somehow watch for it and fall back to the existing digester and dialog "engine" if present. Comments? @Sean - I take it you are using this attribute? Any ideas here? Can you please explain (again) how you use it? There may be other ways to achieve the desired results, from an SCXML PoV. Ofcourse, that will only be applicable for new applications. -Rahul [1] http://people.apache.org/~rahul/shale/style-dialogs/ [2] https://issues.apache.org/struts/browse/SHALE-120 [3] http://svn.apache.org/repos/asf/shale/framework/trunk/shale-core/src/main/java/org/apache/shale/dialog/
