Hi Brian,
The way I see it, the current implementation has some "problems":
- As you say, your custom combobox will always know about the
RoleFilter. (On a sidenote, it might be even better to pass in an
instance of an IRoleFilter so that you have more flexibility in the way
the filter is implemented. You could even define the filter and your
combobox in the applicationContext and have them wired together by the
container at runtime.)
- The fact that you have to create a custom combobox for implementing
security in your application. And would have to do that for every
filtered component.
The most elegant solution for this would be an AOP advice that filters
the dataProvider before assigning it to the consumer/component. The
advantages are:
- the consumer doesn't know anything about the filter
- you don't need to extend the component(s) to add filtering
- the advice can easily be reused and applied to other components with a
dataProvider property. You'd need to alter the pointcut (that defines
where to intercept accessors or methods) which could also be done in the
applicationcontext.
Of course, the downside of this is that it bring a bit of extra
complexity to your application, but IMO that's mostly because we are not
used to thinking in aspects. What do you think?
thx for your input, it is greatly appreciated!
regards,
Christophe
Brian Lesser wrote:
>
> Thanks Carlos,
> I'll be interested to see what you come up with. Right now I'm
> experimenting with the best way to use static methods to handle
> cross-cutting security concerns within custom components. For example a
> combo box may only be able to show certain options to a user based on
> the user's role. The combo starts off with all the options available but
> must filter them before displaying them. To do that it calls a static
> method of a RoleFilter class. I'm not sure if that's the best way to go
> about it though. Here's the script from within a custom combo box as an
> example:
>
> <mx:Script>
> <![CDATA[
>
> import com.somecompany.security.RoleFilter;
>
> private function init():void{
> filterData();
> }
>
> public function filterData():void{
> dataProvider =
> RoleFilter.filterArrayCollection(unfilteredCollection);
> }
>
> ]]>
> </mx:Script>
>
> Note: unfilteredCollection is just an ArrayCollection of objects.
>
> Now, that's not a lot of code, but what bothers me is that I'd rather my
> custom combo box not know anything about my RoleFilter class. In fact
> I'd prefer it not know anything about filters at all. So, even though
> this works fine, I'm trying to come up with something more elegant. So
> far having the combo box's container set this up hasn't looked right
> either. So again, I'm interested to see what you end up with.
>
> Yours truly,
> -Brian
>
> Carlos Rovira wrote:
>
> > I think avoiding repeated code would a great advance if we use an IoC
> > container that allows us only create the different code and inyect the
> > shared functionality. Another great thing is AOP that would be a great
> > thing
> > since many different objects must face equal behaviour and we could do
> > this
> > as as aspect and inyect it by configuration.
> > Maybe the problem is to think about how we must to adapt this kind of
> > functionality to AS3 and Flex and not simply copy from the java/spring
> > world
> > to Flex.
> > But for me is clear that many improvements in the upcoming months
> > could be
> > done with frameworks like Pranaq
> >
> >
> > 2007/4/20, Brian Lesser <[EMAIL PROTECTED]
> <mailto:blesser%40ryerson.ca>>:
> >
> >>
> >> Hi Carlos, et al,
> >>
> >> I have a question regarding the need for an ioc container for Flex as
> >> opposed to a pure AS3 or Flash project. Flex already provides a
> >> hierarchy of containers that contain controls and service proxies. The
> >> containers are usually responsible for setting the dependencies between
> >> controls and proxies. Setting dependencies can be done with
> databinding,
> >> simple assignment, or by setting up listeners. This is a very different
> >> situation from what a Java developer faces without an IOC container
> when
> >> writing servlets or JSP pages. In fact in Flex the built in visual
> state
> >> mechanism means we can set up dependencies and tear them down when
> >> states are entered and left. So, here's my question: what would an IOC
> >> container add that Flex doesn't provide and how would it improve our
> >> work or what we could do? Are you primarily thinking about aspects?
> >>
> >> Yours truly,
> >> -Brian
> >>
> >> Carlos Rovira wrote:
> >>
> >> > Looks very promising :)
> >> >
> >> > Great!
> >> >
> >> > C.
> >> >
> >> > PD:mmm... no body else seems to be interested in this proyect? people
> >> > know about the benefits of a IoC container?
> >> >
> >> > 19 Apr 2007 04:03:30 -0700, Christophe Herreman <
> [EMAIL PROTECTED] com
> >> > <mailto:[EMAIL PROTECTED] <mailto:lists%40herrodius.com>
> <lists%40herrodius.com>>>:
> >> >
> >> > Hi Carlos,
> >> >
> >> > I don't really have an official roadmap, but here are some of the
> >> > things
> >> > I'd like to achieve:
> >> > - IoC container
> >> > - IoC utils for frameworks like Cairngorm and ARP
> >> > - AOP framework
> >> > - Mock Objects for FlexUnit
> >> > - Reflection API
> >> > - general utilities
> >> >
> >> > Reading this myself, it looks very optimistic ;-) but the
> >> > motivation is
> >> > there so, what the heck.
> >> >
> >> > A first version of the Reflection API has just been added to the SVN
> >> > repo BTW.
> >> >
> >> > regards,
> >> > Christophe
> >> >
> >>
> >> --
> >> __________________________________________________________
> >> Brian Lesser
> >> Assistant Director, Application Development and Integration
> >> Computing and Communications Services
> >> Ryerson University
> >> 350 Victoria St.
> >> Toronto, Ontario Phone: (416) 979-5000 ext. 6835
> >> M5B 2K3 Fax: (416) 979-5220
> >> Office: POD?? E-mail: [EMAIL PROTECTED]
> <mailto:blesser%40ryerson.ca> <blesser%40ryerson.ca>
> >> (Enter through LB99) Web:
> >> http://www.ryerson.ca/~blesser
> <http://www.ryerson.ca/%7Eblesser><http://www.ryerson.ca/%7Eblesser
> <http://www.ryerson.ca/%7Eblesser>>
> >> __________________________________________________________
> >>
> >>
> >>
> >
> >
> >
>
> --
> __________________________________________________________
> Brian Lesser
> Assistant Director, Application Development and Integration
> Computing and Communications Services
> Ryerson University
> 350 Victoria St.
> Toronto, Ontario Phone: (416) 979-5000 ext. 6835
> M5B 2K3 Fax: (416) 979-5220
> Office: POD B-66-C E-mail: [EMAIL PROTECTED]
> <mailto:blesser%40ryerson.ca>
> (Enter through LIB-B99) Web: http://www.ryerson.ca/~blesser
> <http://www.ryerson.ca/%7Eblesser>
> __________________________________________________________
>
>
