> Using the designer the user could draw visually the flow between pages
> .. but this is what Seam do with page flow.
This strikes me as doing something shiny just because you can, rather
than because it would be useful. The reason you need this kind of stuff
in Seam is presumably that you end
Paolo Di Tommaso wrote:
> I'm not absolutely specking about a core implementation.
>
> This should regards a Seam or just JBPM integration. JBPM provides a
> very nice process flow designer.
>
> I think would be possible to have a process flow that defines the Wicket
> page and the inner model
I thought about it some more, and now I think hibernate conversations are not
the same as SEAM conversations...
But I should try it out someday before posting more blurred thoughts.
n8han wrote:
>
> Remco Bos wrote:
>> I first thought the conversations / workspace concepts could be usefull,
>
Igor Vaynberg wrote:
> now the instance of this model defines the conversation scope, pass it
> around between pages that need to use the same conversation. or is there
> more to it then that?
I'm not sure if that's an option I tried and rejected; it was a half
year ago. Keeping the sessions in
On 7/6/07, Nathan Hamblen <[EMAIL PROTECTED]> wrote:
The Wicket community is (for now) oriented around IDetachable so it's
easier going that way. And I don't think detaching is a bad way to
work--I use it for everything.
can you also not use idetachable for long conversations? as far as i kn
> This will be labeled "experimental" in Databinder 1.1 probably, but it
> worked very smoothly in the example I cooked up some time ago and have
> let fall off the web (it will be back though; it's replacing the regular
> phone directory app). It's interesting stuff, anyway.
Keep us informed :)
Remco Bos wrote:
> I first thought the conversations / workspace concepts could be usefull, and
> that SEAM could offer a better (or different) solution to the
> OpenSessionInView pattern to manage Hibernate sessions over requests.
The Wicket community is (for now) oriented around IDetachable so i
I'm not absolutely specking about a core implementation.
This should regards a Seam or just JBPM integration. JBPM provides a very
nice process flow designer.
I think would be possible to have a process flow that defines the Wicket
page and the inner model binding-persistence.
Using the designe
pageflow?
like defining the next page in xml file?
and then instead of
setResponsePage(new MyNextPage());
i get
setResponsePage("mynextpageasastring")
if you want something like that then you should really develop then on top
if wicket yourself.
because that won't make it into core.
johan
O
I think it depends how Seam will be really decoupled from JSF.
I think it would be a nice option to Seam users to use Wicket as
presentation layer instead of JSF, but if so the integration should be a
Seam developers matter ..
What would be nice to have in Wicket from an integration with Seam is
I have never used SEAM myself and haven't looked into it in detail.
I first thought the conversations / workspace concepts could be usefull, and
that SEAM could offer a better (or different) solution to the
OpenSessionInView pattern to manage Hibernate sessions over requests.
But maybe seam and
> > I think the BPM feature would be a nice addition.
>
> I'm curious to learn what you would think that should look like. I've
> heard of a couple of projects that used/ integrated Wicket + jBPM
> (likely the default of SEAM) but everyone might have different ideas
> on it. How would you want to u
Here's my 2c:
> I think the BPM feature would be a nice addition.
I'm curious to learn what you would think that should look like. I've
heard of a couple of projects that used/ integrated Wicket + jBPM
(likely the default of SEAM) but everyone might have different ideas
on it. How would you want
I think the BPM feature would be a nice addition.
I'm currently also working with a Tapestry 3 project that integrated with
Spring WebFlow. The integration is a bit hairy, but having the state
machine for flow management was a big win. The cost is that virtually any
link that moves from one pag
> So... who's gonna pick it up and start a wicket-stuff project for this? :)
Maybe a good start would be to define the case for it. Having an
integrated stack can be valueable, and this is where I can imagine
Seam integration being really helpful. Would Wicket + Seam be enough
to provide a whole a
> I'm quoting Gavin King:
> `By the way, it's now possible (easy, in fact) to build Wicket integration
> for Seam (...) I imagine it would be interesting to the Wicket community to
> have Seam's contextual component model, conversations, BPM integration,
> persistence context management, EJB3 integ
16 matches
Mail list logo
