OM User and domain-specific extensions

[Greg Kerdemelidis <gr...@genixsystems.com>]

Hi all,

It has become apparent after following this list for a while that there are
a number of different approaches going down in terms of fitting Turbine (et
al) into your web apps.

A number of people have followed the "Extending User" howto and have
constructed custom user classes with good success.

Others have left turbine/torque to their own devices, and built extra OM
objects with rows indexed by the turbine user key.

What I'm curious about is the different ways in which people have extended
the OM model in their own projects; the pro's and con's. I feel that this
would be an extremely useful reference for further developers, as it's an
area which is left to the architect to figure out, and there's a bit of a
void in terms of information.

Perhaps it's up to the individual requirements of the project, but there are
a couple of main directions to go in terms of "design patterns" as far as I
can see:

1) Extend the Torque user model, and work it into the turbine security
model. This has been covered elsewhere. Check the site resources.

2) Leave turbine/torque to do what they like, and use a supplementary OM to
map your requirements. This is the option I go for, mainly because I favor
Hibernate and EJBs, but not Torque (this is a combination of personal
preference, company policy, and requirements). I'll construct the OM and
basic database for the Turbine project, and just subclass the Flux adduser
action (and update the TR.props accordingly) to add some extra "create user"
code that makes sense to my application. The way I see it, it's even better
to create a seperation of your framework (& security playground) from your
domain-specific code. Easy way to do it: map userIDs from turbine -> back
tier via some snazzy code and implement some extra authentication code. I
mean, you're going to have to do that (write extra code) if you're doing
anything bigger than a webapp anyway, so it makes sense to loosely couple
the layers, no?

Number (2) tends to favor 3-tier apps where the bulk of the "meaning" for a
"user" is in the business logic, not the presentation tier.

How are other people implementing their domain-specific extensions to the
model?

Regards,

Greg Kerdemelidis


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

RE: OM User and domain-specific extensions

[Eric Pugh <ep...@upstate.com>]

I am successfully leveraging the Fulcrum Security components multiple
"models"/multiple implementations approach.  I use the Memory implementation
in my unit testing to reduce the startup/runtime for my unit tests.  Then in
integration and run time I swap in the Hibernate version.   Hibernate has
the wonderful ability that I can subclass the User object, and add my
additional columns etc, and then when I save, because I have a custom
mapping file, all the extra columns etc save back.  Much simpler then the
torque method...

I am soon going to be in the process of breaking the API for fulcrum
security out into it's own jar, with multiple implmentation projects so that
you just pick your implementation and are done..

eric

> -----Original Message-----
> From: Greg Kerdemelidis [mailto:greg@genixsystems.com]
> Sent: Wednesday, November 19, 2003 10:16 AM
> To: Turbine User List
> Subject: OM User and domain-specific extensions
>
>
>
> Hi all,
>
> It has become apparent after following this list for a while
> that there are
> a number of different approaches going down in terms of
> fitting Turbine (et
> al) into your web apps.
>
> A number of people have followed the "Extending User" howto and have
> constructed custom user classes with good success.
>
> Others have left turbine/torque to their own devices, and
> built extra OM
> objects with rows indexed by the turbine user key.
>
> What I'm curious about is the different ways in which people
> have extended
> the OM model in their own projects; the pro's and con's. I
> feel that this
> would be an extremely useful reference for further
> developers, as it's an
> area which is left to the architect to figure out, and
> there's a bit of a
> void in terms of information.
>
> Perhaps it's up to the individual requirements of the
> project, but there are
> a couple of main directions to go in terms of "design
> patterns" as far as I
> can see:
>
> 1) Extend the Torque user model, and work it into the turbine security
> model. This has been covered elsewhere. Check the site resources.
>
> 2) Leave turbine/torque to do what they like, and use a
> supplementary OM to
> map your requirements. This is the option I go for, mainly
> because I favor
> Hibernate and EJBs, but not Torque (this is a combination of personal
> preference, company policy, and requirements). I'll construct
> the OM and
> basic database for the Turbine project, and just subclass the
> Flux adduser
> action (and update the TR.props accordingly) to add some
> extra "create user"
> code that makes sense to my application. The way I see it,
> it's even better
> to create a seperation of your framework (& security
> playground) from your
> domain-specific code. Easy way to do it: map userIDs from
> turbine -> back
> tier via some snazzy code and implement some extra
> authentication code. I
> mean, you're going to have to do that (write extra code) if
> you're doing
> anything bigger than a webapp anyway, so it makes sense to
> loosely couple
> the layers, no?
>
> Number (2) tends to favor 3-tier apps where the bulk of the
> "meaning" for a
> "user" is in the business logic, not the presentation tier.
>
> How are other people implementing their domain-specific
> extensions to the
> model?
>
> Regards,
>
> Greg Kerdemelidis
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org


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