Re: [PROPOSAL] Open the Shale Sandbox to any interested Apache committer
On 8/31/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: I propose that we do the same, and open the Shale Sandbox to any existing Apache committer who would like to collaborate on Shale-related projects. +1 Craig
Re: [dialog] Progress on weekend experiments
On 8/31/06, Sean Schofield <[EMAIL PROTECTED]> wrote: @Craig, Two questions regarding your initial check in ... 1.) Why doesn't the navigation handler call render response after setting the view? Is that something that is frowned upon? I noticed the myfaces implementation does this (perhaps incorrectly.) Doing this would be redundant in the normal case, because the navigation handler is called during Invoke Application phase, so the next phase is going to be Render Response anyway. The possible exception is if you set immediate="true" on the command component that submitted the form ... but the default ActionListener that calls your action method (and then invokes the navigation handler) is supposed to have already called renderResponse before it returns. It wouldn't hurt anything to call it, though, as paranoid protection against potential JSF implementation bugs. 2.) Why does LegacyContext need a reference to Contexts? Its currently not being used. No big deal - I know its the sandbox - but did you have something in mind for this reference? In other conversations on the topic, it seems like some event broadcasting might allow the application to specialize its behavior based on what is going on ... and it would likely be more convenient for the application to register its event listeners on the session-scoped LegacyContexts object, rather than the request scoped LegacyContext object where the reference comes and goes each request (although it is indeed the same instance. Also, this would allow us to move the "exit from a dialog programmatically" logic from the remove() method on LegacyContexts to some sort of close() method on LegacyContext ... which might be better usability. Off to create a few test dialogs. I will report back shortly. Sean Craig On 8/31/06, Sean Schofield <[EMAIL PROTECTED]> wrote: > On 8/28/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > I've checked in some progress on my experiments with how we can improve the > > Dialog functionality. Even though they're not done yet, they are far enough > > along to want some feedback and to make them available for experimentation > > and further development. This mail will serve as a record of my thinking so > > far, so you can get a feel for why I took the approach I've taken so far. > > Great. I think we should do more of this sandbox in progress type > stuff. Its easier to contribute your own ideas if the other person > hasn't nailed everything down yet. > > > Initially, I wanted to address two shortcomings and one expanded feature in > > our current approach: > > > > * Make it possible for a single user to have multiple active dialog > > instances > > (although limited to one per JSF view, per our discussion). > > Great. I see this also handles the "aborted" dialog case (user closes > popup window.) Nicely done. > > > * Make it possible to programmatically start up a dialog instance, as well > > as > > start one with a prefix on a logical outcome. > > This will be real nice. I see how the create method establishes a > context but will this work in a popup scenario? User clicks on a > "Start dialog" link and the dialog starts in a new popup window. I'm > thinking one could use a view controller for your pop up window and > call the necessary create method. Does the programmer need to find > the first page of the dialog on their own in this instance? > > > * Make it possible to plug in different state machine implementations > > (i.e. Commons SCXML), perhaps with different detailed feature sets. > > I nice to have bonus. > > > I have *not* tried to address synchronizing state when the user presses the > > browser navigation buttons yet. One can of worms at a time :-). Rahul had > > some comments earlier today on how SWF deals with this. Seam does something > > similar, and we'll undoubtedly need to add functionality here later. > > Don't worry. We're not going to solve this anytime soon. > > > To address these initial concerns, I focused first on abstracting out the > > APIs that an application *using* the dialog feature should have to interact > > with, and then providing generic integration for the navigation handler that > > can start a new dialog, or operate an existing one. The guts of actually > > processing the transitions, then, is delegated to a state-machine-specific > > implementation. The key APIs are (so far) incredibly simple -- they are in > > the "shale-dialog2" module in the sandbox. There are two fundamental > > interfaces: > > > > org.apache.shale.dialog2.Context: > > > > * Represents the current state of an active dialog instance (similar to > > Status in the current implementation) > > > > * One instance per active dialog, rather than one per user > > > > * Cached in a o.a.s.dialog2.Contexts object stored in session scope (see > > below) > > in between requests > > > > * Generic phase listener (o.a.s.dialog2.faces.Dialog2PhaseListener) is > > responsible > >
[PROPOSAL] Open the Shale Sandbox to any interested Apache committer
The Jakarta Commons sandbox is open [1] to any Apache committer who expresses an interest in working there, and the Maven developers are discussing [2] the addition of an open sandbox area for plugin development. I propose that we do the same, and open the Shale Sandbox to any existing Apache committer who would like to collaborate on Shale-related projects. [1] (I don't see the policy on the Commons Sandbox website, but I know I've seen it mentioned on the dev list.) [2] http://www.nabble.com/Maven-Sandbox-for-Apache-Committers-t2186725.html -- Wendy
Re: [dialog] Progress on weekend experiments
@Craig,
Two questions regarding your initial check in ...
1.) Why doesn't the navigation handler call render response after
setting the view? Is that something that is frowned upon? I noticed
the myfaces implementation does this (perhaps incorrectly.)
2.) Why does LegacyContext need a reference to Contexts? Its
currently not being used. No big deal - I know its the sandbox - but
did you have something in mind for this reference?
Off to create a few test dialogs. I will report back shortly.
Sean
On 8/31/06, Sean Schofield <[EMAIL PROTECTED]> wrote:
On 8/28/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> I've checked in some progress on my experiments with how we can improve the
> Dialog functionality. Even though they're not done yet, they are far enough
> along to want some feedback and to make them available for experimentation
> and further development. This mail will serve as a record of my thinking so
> far, so you can get a feel for why I took the approach I've taken so far.
Great. I think we should do more of this sandbox in progress type
stuff. Its easier to contribute your own ideas if the other person
hasn't nailed everything down yet.
> Initially, I wanted to address two shortcomings and one expanded feature in
> our current approach:
>
> * Make it possible for a single user to have multiple active dialog
> instances
> (although limited to one per JSF view, per our discussion).
Great. I see this also handles the "aborted" dialog case (user closes
popup window.) Nicely done.
> * Make it possible to programmatically start up a dialog instance, as well
> as
> start one with a prefix on a logical outcome.
This will be real nice. I see how the create method establishes a
context but will this work in a popup scenario? User clicks on a
"Start dialog" link and the dialog starts in a new popup window. I'm
thinking one could use a view controller for your pop up window and
call the necessary create method. Does the programmer need to find
the first page of the dialog on their own in this instance?
> * Make it possible to plug in different state machine implementations
> (i.e. Commons SCXML), perhaps with different detailed feature sets.
I nice to have bonus.
> I have *not* tried to address synchronizing state when the user presses the
> browser navigation buttons yet. One can of worms at a time :-). Rahul had
> some comments earlier today on how SWF deals with this. Seam does something
> similar, and we'll undoubtedly need to add functionality here later.
Don't worry. We're not going to solve this anytime soon.
> To address these initial concerns, I focused first on abstracting out the
> APIs that an application *using* the dialog feature should have to interact
> with, and then providing generic integration for the navigation handler that
> can start a new dialog, or operate an existing one. The guts of actually
> processing the transitions, then, is delegated to a state-machine-specific
> implementation. The key APIs are (so far) incredibly simple -- they are in
> the "shale-dialog2" module in the sandbox. There are two fundamental
> interfaces:
>
> org.apache.shale.dialog2.Context:
>
> * Represents the current state of an active dialog instance (similar to
> Status in the current implementation)
>
> * One instance per active dialog, rather than one per user
>
> * Cached in a o.a.s.dialog2.Contexts object stored in session scope (see
> below)
> in between requests
>
> * Generic phase listener (o.a.s.dialog2.faces.Dialog2PhaseListener) is
> responsible
> for saving and restoring access to the right instance:
>
> - Before render response, caches the identifier of the currently ative
> instance
> (if any) in the JSF component tree, as a generic attribute of the view
> root.
>
> - After restore view, pulls the dialog identifier out, grabs the cached
> Context
> instance from the session scope Contexts object, and exposes it as a
> request
> scope attribute under a well known key ("dialog2" for the moment).
>
> * As we did in the original impl, Context exposes a "data" property for the
> app to
> store whatever it wants. So, binding expressions work very similarly to
> what they
> did before ("#{dialog2.data.name}"), but with the bugfix that it is one
> instance per view
> instead of one instance per user.
>
> * Contains an advance() method that can be called to have the state machine
> work its
> way through the transitions until it runs into a state that needs input
> from the user (in
> the terminology of the existing impl, that means when you hit a view
> state). The advance
> method returns the view id of the page to display, and a generic
> navigation handler
> implementation (o.a.s.dialog2.faces.Dialog2NavigationHandler) then does
> the actual
> JSF navigation. NOTE - this navigation handler is generally the only code
> that should
> call this method.
Context stuff looks good. I'm going to try creating a few di
Re: [dialog] Progress on weekend experiments
On 8/28/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
I've checked in some progress on my experiments with how we can improve the
Dialog functionality. Even though they're not done yet, they are far enough
along to want some feedback and to make them available for experimentation
and further development. This mail will serve as a record of my thinking so
far, so you can get a feel for why I took the approach I've taken so far.
Great. I think we should do more of this sandbox in progress type
stuff. Its easier to contribute your own ideas if the other person
hasn't nailed everything down yet.
Initially, I wanted to address two shortcomings and one expanded feature in
our current approach:
* Make it possible for a single user to have multiple active dialog
instances
(although limited to one per JSF view, per our discussion).
Great. I see this also handles the "aborted" dialog case (user closes
popup window.) Nicely done.
* Make it possible to programmatically start up a dialog instance, as well
as
start one with a prefix on a logical outcome.
This will be real nice. I see how the create method establishes a
context but will this work in a popup scenario? User clicks on a
"Start dialog" link and the dialog starts in a new popup window. I'm
thinking one could use a view controller for your pop up window and
call the necessary create method. Does the programmer need to find
the first page of the dialog on their own in this instance?
* Make it possible to plug in different state machine implementations
(i.e. Commons SCXML), perhaps with different detailed feature sets.
I nice to have bonus.
I have *not* tried to address synchronizing state when the user presses the
browser navigation buttons yet. One can of worms at a time :-). Rahul had
some comments earlier today on how SWF deals with this. Seam does something
similar, and we'll undoubtedly need to add functionality here later.
Don't worry. We're not going to solve this anytime soon.
To address these initial concerns, I focused first on abstracting out the
APIs that an application *using* the dialog feature should have to interact
with, and then providing generic integration for the navigation handler that
can start a new dialog, or operate an existing one. The guts of actually
processing the transitions, then, is delegated to a state-machine-specific
implementation. The key APIs are (so far) incredibly simple -- they are in
the "shale-dialog2" module in the sandbox. There are two fundamental
interfaces:
org.apache.shale.dialog2.Context:
* Represents the current state of an active dialog instance (similar to
Status in the current implementation)
* One instance per active dialog, rather than one per user
* Cached in a o.a.s.dialog2.Contexts object stored in session scope (see
below)
in between requests
* Generic phase listener (o.a.s.dialog2.faces.Dialog2PhaseListener) is
responsible
for saving and restoring access to the right instance:
- Before render response, caches the identifier of the currently ative
instance
(if any) in the JSF component tree, as a generic attribute of the view
root.
- After restore view, pulls the dialog identifier out, grabs the cached
Context
instance from the session scope Contexts object, and exposes it as a
request
scope attribute under a well known key ("dialog2" for the moment).
* As we did in the original impl, Context exposes a "data" property for the
app to
store whatever it wants. So, binding expressions work very similarly to
what they
did before ("#{dialog2.data.name}"), but with the bugfix that it is one
instance per view
instead of one instance per user.
* Contains an advance() method that can be called to have the state machine
work its
way through the transitions until it runs into a state that needs input
from the user (in
the terminology of the existing impl, that means when you hit a view
state). The advance
method returns the view id of the page to display, and a generic
navigation handler
implementation (o.a.s.dialog2.faces.Dialog2NavigationHandler) then does
the actual
JSF navigation. NOTE - this navigation handler is generally the only code
that should
call this method.
Context stuff looks good. I'm going to try creating a few dialogs
later tonight to actually test it out. Maybe even add some test
cases.
org.apache.shale.dialog2.Contexts:
The name confuses me. I would prefer to call it ContextManager or
something like that. IMO its too confusing (visually) to have Context
and Contexts. They are too similar looking and I find myself stopping
and saying "Now which one is it again?"
* Defined by a particular implementation as a session scoped managed bean
that is
stored under a well known key.
* Maintains a cache of Context instances for the current user, keyed by
dialog identifiers,
so we get the one-per-view capability.
* Includes a create() method so that you can programmatically start a dialog
in
Re: PROPOSAL Voting For the Logo Contest
On Aug 30, 2006, at 11:19 PM, James Mitchell wrote: One thing that isn't 100% nailed down is the actual voting. Do we want to post our votes to [EMAIL PROTECTED] Or [EMAIL PROTECTED] Or setup a quick web- based poll to keep the votes hidden until the time expires. I think all votes should be to [EMAIL PROTECTED] The purpose of the contest was to get people to subscribe there anyway. I don't have a problem with PMC and community votes going to the same place. I do think we need to keep two separate tallies, but I think if the two groups come up with vastly different results we should seriously consider whether we want to stick to our guns or not. Greg
Re: PROPOSAL Voting For the Logo Contest
On Aug 30, 2006, at 6:26 PM, Sean Schofield wrote: I agree with locking the page down. I don't have any problem with the system as proposed but I think we should add a second round of voting. Lets shorten the initial vote to 7 days. If you miss out on the voting in the first round there's still a second round. That wouldn't bother me. Take the top 5 (weighted) choices of the PMC. If the users top choice is something that is not in the top 5 then substitute the 5th choice for the user's top choice. Then repeat the voting for another 7 days. I dunno. I think maybe the PMC should discuss our course of action if the community's vote is vastly different from our own. We may decide to go with the community's choice instead in an effort to build momentum -- or we may really not like their choice and choose to go with our own. Greg
