shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <rahul.akol...@gmail.com>
Subject Re: [dialog] className attribute
Date Fri, 25 Aug 2006 22:01:24 GMT
On 8/25/06, Craig McClanahan <craigmcc@apache.org> wrote:
> On 8/25/06, Rahul Akolkar <rahul.akolkar@gmail.com> 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?
>
<snip/>

Not in v0.5 the way its done in Shale dialogs -- Commons SCXML uses
the ObjectCreateRule(Class) constructor on most elements, rather than
(String,Class). But that probably doesn't matter, since the class
specified by the className would be Shale dialog internals specific,
and would be alien when ported over.


> * 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.
<snap/>

I don't think so:

 * SCXML provides reasonable mechanisms to do "non-standard" things
without having to augment the underlying models (custom actions,
custom semantics, for example).

 * What you said in the line below.

Anyway, since I didn't follow the className addition in Shale dialogs
closely, we might have luck with a concrete usecase or two on the
table (lets see if these pop up). ATM, I'm not thinking about new
apps, I think we will probably have decent mechanisms to support any
app-specific add-ons using SCXML -- its more a statement about
existing apps that already use this attribute, and brainstorming the
best way to fit those into the porting exercise we're trying here.

Wouldn't it be great if we could look into a crystal ball and see how
people are actually using this attribute?

-Rahul


>   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/
> >
>
>

Mime
View raw message