> > That's good idea using the Shale filter commands. Seems like a great place
> > to
> capture state at a page level and if the managed beans are defined in request
> scope, you wouldn't have to clone the object before pushing on the context
> stack.
>
> Just so you know I was refering to th
> That's good idea using the Shale filter commands. Seems like a great place
> to capture state at a page level and if the managed beans are defined in
> request scope, you wouldn't have to clone the object before pushing on the
> context stack.
Just so you know I was refering to the Filter cl
> Gary,
>
> I agree that EJB can be overkill in some instances. I wanted to use
> transactions in my COR solution so I did some cool stuff with
> commons-chain. I used the "Filter" object (extends Command) which
> guarantees that its postprocess method will be called if its execute
> method is c
#x27;t consider that. I guess that I was thinking in terms of being
> able to create a transactional unit-of-work on a non distributed object, a
> simple POJO. I guess that EJB3 will do that but not in a simple web module.
>
> >>Gary
> >
> >
> >Craig
>
> G
>> > [snip]
>> >
>> > > I take it this is to avoid keeping the list around when you don't need
>> it (
>> > > i.e. you're not on the view containing the Ajax component)? I
>> presumeit must
>> > > be relatively cheap to populate the overall list in the first place?
>> >
>> > Yes that is the point.
On 11/14/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
> > You mentioned the action method in your previous email, I presume you
> > were refering to the DialogNavigationHandler's action method? That
> > would potentially tie behavior specific to this dialog (clearing some
> > backing bean) to the
On 11/14/05, Gary VanMatre <[EMAIL PROTECTED]> wrote:
>
> > [snip]
> >
> > > I take it this is to avoid keeping the list around when you don't need
> it (
> > > i.e. you're not on the view containing the Ajax component)? I
> presumeit must
> > > be relatively cheap to populate the overall list in t
> You mentioned the action method in your previous email, I presume you
> were refering to the DialogNavigationHandler's action method? That
> would potentially tie behavior specific to this dialog (clearing some
> backing bean) to the generic dialog processing, which would make that
> approach far
> [snip]
>
> > I take it this is to avoid keeping the list around when you don't need it (
> > i.e. you're not on the view containing the Ajax component)? I presumeit
> > must
> > be relatively cheap to populate the overall list in the first place?
>
> Yes that is the point. Its cheap enugh
On 11/14/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
>
> > Session scope makes sense (versus request), obviously, because the
> > individual asynchronous requests will all be different. Whether it makes
> > more sense than application scope is pretty much requirements dependent, but
> > in gener
[snip]
> I take it this is to avoid keeping the list around when you don't need it (
> i.e. you're not on the view containing the Ajax component)? I presumeit must
> be relatively cheap to populate the overall list in the first place?
Yes that is the point. Its cheap enugh to create it for each
Craig McClanahan wrote:
Since URL rewriting is a server side thing, you'd want to make sure you
did the rewriting as you rendered the JavaScript code that will compute
the URL to which the asynch request should be sent.
Yeah, that's probably true... I was confusing myself thinking a browser
d
On 11/14/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
>
> Craig McClanahan wrote:
> > Reminds me of something I haven't actually verified ... does the session
> > cookie get sent in by an XmlHttpRequest?
>
> Yes, it does. All cookies from the originating domain are sent
> automatically, includi
Craig McClanahan wrote:
Reminds me of something I haven't actually verified ... does the session
cookie get sent in by an XmlHttpRequest?
Yes, it does. All cookies from the originating domain are sent
automatically, including the session cookie, just like any other HTTP
request.
I'm not s
On 11/14/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
>
> I was hoping for some feedback on this design approach ..
>
> I have a dialog with several different screens. One of the screens is
> using inputSuggestAjax (a MyFaces - Tomahawk component.) The list of
> choices that backs this input compo
15 matches
Mail list logo
