Quoting Jason van Zyl <[EMAIL PROTECTED]>:
> On 6/12/01 12:47 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
> > Quoting Jason van Zyl <[EMAIL PROTECTED]>:
> >
> >>> 2.) jason said he would like to move the classes to the apps - i'm
> not
> >> sure
> >>> about this
> >>
> >> Move the classes to the apps? I don't understand.
> >
> > as i remeber you said it would be better to generate the om/peer
> classes
> > within
> > the package-structure of the apps (e.g. jyve)
> >
> > sorry if missunderstood something ...
>
> If a user class is being generated specifically for the application
> than I definitely think it should be part of the application. I think
> this will only be configuration information. You will probably have
> an XML schema describing the user and this will be part of your
> applications configuration information. Torque should take the
> schema and do the rest.
+1
seems ther is a communication problem ... maybe i should take some
english conversation classes ;-)
> >>> - if we move the classes out of turbine - what happens with the
> >> ldap
> >>> implementation?
> >>> - i would prefer to keep the basic-implementation within turbine
> and
> >> add
> >>> functionality
> >> to the tdk which makes it easy to use your own user-table
> >>
> >> I don't think we disagree here.
> >
> > great ;-)
> >
> > any suggestions for the package for the om/peer classes??
> > org.apache.turbine.om.security?
>
> Which ones? If you're talking about the reworking of the security
> code as per the security proposal than I think we wanted to change
> the location of them.
ok, where should they live??
> If you are talking about generated classes for the application
> than they definitely shouldn't be in the turbine package structure.
> A generated user class is application specific so I don't think
> it belongs in the Turbine package structure.
the definition will be in project-schma.xml .. so this is handled by torque.
what we need is a implementation for the UserManager interface
(com.company.project.security.ProjectUserManager)
it should also be possible to use the application-user-class with flux
(also the UserForm.vm could be generated to make the added attributes available
for the admin ;-)
martin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]