What does your Default.class look like?
Well, more specifically, how do you get the authorization tool for the current user so you can check their permissions against your Security Service? Thanks, Skip > -----Original Message----- > From: Weaver, Scott [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 07, 2002 10:57 AM > To: 'Turbine Users List' > Subject: RE: Semi-Newbie. Is newapp push or pull? > > > IMOHO, pull is the way to go. You get an immense amount of > re-usability and > flexibility by using a pull model. > > Example, if some decides that they want to re-design the > entire look, feel > and flow an application. As the web engineer, there is very > little you will > have to do accomplish this since your logic (pull tools) is > de-coupled from > the view (templates). > > My "One screen to bind them all" example. > > My application has just one screen class that acts as a > secure, single point > of entry for security and authorization. Since it is the only screen > class, it is named "Default.class" and resides at the top of my module > hierarchy for screens which means it is called for every > template. This > screen class extracts the name of the template to be > processed and passes it > to a session pull tool that is assigned to each user as they > log in. The > session pull tool communicates with a security service that > uses an xml file > to tie security requirements (groups, roles and permissions) > to a template > (I also use it for actions, action events and component > authorization). > Once the requirements for that template have been extracted, > the pull tool > compares this to the user's ACL. If security is satisfied > the pull returns > true and the screen class allows the presentation of the template if > security is not satisfied the pull tool returns false and the > screen class > redirects to an authorization failure page. > > This makes changing security requirements for a template a > snap. All a web > designer has to do is go into xml file that defines security > and add what > the requirements are for that template. Not one single line > of code has to > written. What is even nicer is that I can easily take the > security pull > tool and use it directly within a template or use it from > within an action. > > This is just one example of the advantage of using pull tools with the > fulcrum service framework opposed to locking your code within > individual > screen classes (push model). > > > hth, > Scott > > > -----Original Message----- > > From: Mark Nutter [mailto:[EMAIL PROTECTED]] > > Sent: Monday, May 06, 2002 7:45 PM > > To: Turbine Users List > > Subject: Re: Semi-Newbie. Is newapp push or pull? > > > > > > On Sun, 2002-05-05 at 17:27, Bill Holloway wrote: > > > Gulp. OK. That steepens the learning curve -- maybe -- I > > was wondering > > > what all the "Flux" stuff was. > > > > > > Are there any users of this "mixed" model out there who > > have an opinion on > > > its stability/usability? Thanks. > > > > It's very useful, but each model has its place. > > > > Push model: I have a Java class tied to a particular screen (or > > layout), and the Java class pushes the data to that particular > > screen/layout. The data is available only to that > particular screen. > > Good for special purpose applications, e.g. restricted-access admin > > functions. > > > > Pull model: I have a Java class that creates data that might > > be useful > > on any number of arbitrary pages, and I can include that data on any > > screen or layout I want. The nice thing about pull model > is that you > > can define dynamic data, and make it available to less-technical > > designer types, without having to know or care which screen > > or template > > it appears on. For example, if you have a Localinfo pull > service that > > defines a time(), date() and weather() method, you can tell > your HTML > > pushers that they can easily include dynamic time, date, and weather > > info in their pages just by inserting tags that say > > > > $localinfo.time() > > $localinfo.date() > > $localinfo.weather() > > > > They can put that much on a 3x5 card, and then design the web site > > however they like. > > > > The difference between push and pull is strictly a matter of how the > > dynamic objects get put into the Velocity context. In the > > push model, a > > screen-specific or layout-specific class puts the dynamic > object into > > the context for that particular screen/layout. In the pull > model, the > > pull service put the dynamic object(s) into the Velocity > > context of all > > screens and layouts. In fact, the pull service puts the > objects into > > the contexts of screens and layouts that have push-model > > objects, so if > > you have a screen that uses the push model, you can use > both push and > > pull in the same screen. > > > > Caveat: I'm still learning Turbine, so if I'm misrepresenting > > something, feel free to correct me, but I believe that's correct. > > > > Mark Nutter > > [EMAIL PROTECTED] > > > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
