Migration to Tapestry

[Detlef Schulze <d....@iliuk.com>]

Hi,

the company I work for has a quite large application which is based on
jboss/tomcat and that uses a homegrown framework for the webpart
(dispatcher servlet that follows the model 2 servlet approach with
velocity as templating engine for the html).

The dispatcher servlet does quite a lot in terms of
authentication/authorization.

It now has been decided that we want to use tapestry for the webpart.

Since the application is quite large, we figured out that it is simply
not possible to do a "hard" migration and migrate everything to
tapestry. Therefore it is my task to find out if it is feasible for us
to simply add tapestry to the application and to use it for all new
features/pages that will be added to the application. The first thing
that should be done with tapestry is the administration part for jBPM,
that will be integrated soon.

I have experience with tapestry 3 (I am the only one on the team that
has experience with tapestry) but I never had to work on an application
that uses tapestry in addition to an old fashioned dispatcher servlet
solution.

Two problems come to my mind: session handling (the user definitely
don't want to log in twice) and authentication/authorization (which
includes LDAP authentication) which must be integrated. Once the user is
logged in, the transition from the velocity pages to the tapestry part
must be transparent.

I may have overlooked a whole bunch of other issues, but the basic
question is: has anybody done something similar? What other issues do I
have overlooked and how could they be solved?

Thanks for any hint or tip ...

Cheers,
Detlef

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org

Re: Migration to Tapestry

[Henri Dupre <he...@gmail.com>]

On 5/5/06, Chris Chiappone <ch...@gmail.com> wrote:
>
> I should have mentioned that our homegrown framework is EJB and jsp's.
> Would there be any issue with tapestry accessing the EJB's.  I'm used to
> hibernate but  I don't see it working in this project mainly because of
> the
> large database size, and the fact that keeping hibernate in sync with any
> changes to the database that I don't have control over would be
> frustrating.


I'm not sure to understand your issue with hibernate... Hibernate will keep
in sync data the way you configure it.
We just implemented a 150 tables (with billions of rows) app with
hibernate... The learning curve is more than step though but there is hardly
anything you can't achieve with hibernate.
Anyway this shouldn't have any impact with your tapestry integration...
Tapestry is not tied to any data layer.
I just mentioned Spring because it has built-in mecanisms to share data
accross servlets and filters.

Henri.

Re: Migration to Tapestry

[Chris Chiappone <ch...@gmail.com>]

I should have mentioned that our homegrown framework is EJB and jsp's.
Would there be any issue with tapestry accessing the EJB's.  I'm used to
hibernate but  I don't see it working in this project mainly because of the
large database size, and the fact that keeping hibernate in sync with any
changes to the database that I don't have control over would be frustrating.

On 5/5/06, Henri Dupre <he...@gmail.com> wrote:
>
> On 5/5/06, Detlef Schulze <d....@iliuk.com> wrote:
> >
> > Hi,
> >
> > the company I work for has a quite large application which is based on
> > jboss/tomcat and that uses a homegrown framework for the webpart
> > (dispatcher servlet that follows the model 2 servlet approach with
> > velocity as templating engine for the html).
> >
> > The dispatcher servlet does quite a lot in terms of
> > authentication/authorization.
> >
> > It now has been decided that we want to use tapestry for the webpart.
> >
> > Since the application is quite large, we figured out that it is simply
> > not possible to do a "hard" migration and migrate everything to
> > tapestry. Therefore it is my task to find out if it is feasible for us
> > to simply add tapestry to the application and to use it for all new
> > features/pages that will be added to the application. The first thing
> > that should be done with tapestry is the administration part for jBPM,
> > that will be integrated soon.
> >
> > I have experience with tapestry 3 (I am the only one on the team that
> > has experience with tapestry) but I never had to work on an application
> > that uses tapestry in addition to an old fashioned dispatcher servlet
> > solution.
> >
> > Two problems come to my mind: session handling (the user definitely
> > don't want to log in twice) and authentication/authorization (which
> > includes LDAP authentication) which must be integrated. Once the user is
> > logged in, the transition from the velocity pages to the tapestry part
> > must be transparent.
>
>
> I don't know all the details of your applications but our app is 90%
> tapestry based and we have two additional servlets. I had no difficulties
> making them live together. They don't share much state though, only the
> Spring/Hibernate stuff.
> The major challege for integrating with another framework, is to handle
> links properly. With friendly URLS, and Tapestry 4, this has become much
> more easier. It is probably not difficult to wire into your existing app a
> framework that generates tapestry links and in tapestry you can easily
> write
> a component that generates links back to your old app. This will make the
> transition transparent.
>
> Concerning sharing state, this shouldn't be any problem if your both app
> are
> inside the same web.xml. You can always access the lower servlet API in
> tapestry and directly hack into the servlet session. Spring for instance
> has
> a nice API that allows to share Spring state accross different apps. It
> might even be possible to access the tapestry's ASOs outside tapestry.
>
> Thanks,
>
> Henri.
>
>


--
~chris

Re: Migration to Tapestry

[Henri Dupre <he...@gmail.com>]

On 5/5/06, Detlef Schulze <d....@iliuk.com> wrote:
>
> Hi,
>
> the company I work for has a quite large application which is based on
> jboss/tomcat and that uses a homegrown framework for the webpart
> (dispatcher servlet that follows the model 2 servlet approach with
> velocity as templating engine for the html).
>
> The dispatcher servlet does quite a lot in terms of
> authentication/authorization.
>
> It now has been decided that we want to use tapestry for the webpart.
>
> Since the application is quite large, we figured out that it is simply
> not possible to do a "hard" migration and migrate everything to
> tapestry. Therefore it is my task to find out if it is feasible for us
> to simply add tapestry to the application and to use it for all new
> features/pages that will be added to the application. The first thing
> that should be done with tapestry is the administration part for jBPM,
> that will be integrated soon.
>
> I have experience with tapestry 3 (I am the only one on the team that
> has experience with tapestry) but I never had to work on an application
> that uses tapestry in addition to an old fashioned dispatcher servlet
> solution.
>
> Two problems come to my mind: session handling (the user definitely
> don't want to log in twice) and authentication/authorization (which
> includes LDAP authentication) which must be integrated. Once the user is
> logged in, the transition from the velocity pages to the tapestry part
> must be transparent.


I don't know all the details of your applications but our app is 90%
tapestry based and we have two additional servlets. I had no difficulties
making them live together. They don't share much state though, only the
Spring/Hibernate stuff.
The major challege for integrating with another framework, is to handle
links properly. With friendly URLS, and Tapestry 4, this has become much
more easier. It is probably not difficult to wire into your existing app a
framework that generates tapestry links and in tapestry you can easily write
a component that generates links back to your old app. This will make the
transition transparent.

Concerning sharing state, this shouldn't be any problem if your both app are
inside the same web.xml. You can always access the lower servlet API in
tapestry and directly hack into the servlet session. Spring for instance has
a nice API that allows to share Spring state accross different apps. It
might even be possible to access the tapestry's ASOs outside tapestry.

Thanks,

Henri.