In the gui meta model, both gui modules and tasks have a name. It is not
possible to assign this name from dsl right now. It should in theory be
possible to have several with different names for same backend domainobject,
but i'm only guessing, must be tried to understand the implications.
An alternative is to use the new feature of using non-persistent
valueobjects or DTOs in the gui, which Andreas has implemented recently.
Then the services can expose different DTOs for different purposes. You have
to manually map DTOs to domainobjects in the services. Maybe this is not
what you are looking for, since it might result in a lot of duplication if
you only need to supress a few fields, but if you are looking for completely
different views it is a flexible solution.
/Patrik
greatfooty wrote:
>
> I agree that ultimately the access needs to be controlled at the service
> tier rather than woven into presentation but I think i created a diversion
> by mentioning security in with this issue.
>
> What I'm more keen to investigate is a neat way to have multiple flavours
> of the same functionality and for a ui app to be capable of satisfying the
> needs of different types of users but without that necessarily being
> permissions based, more based around what is the view that is relevant for
> a type (role). I'm saying 'role' here because I'd see that as simplest way
> to group users together given that we would have those roles available in
> whatever security solution is chosen for sculptor.
>
> To date I've played with lockdown of functionailty using regular JEE
> declarative authorisation via url-patterns and JEE roles described inside
> web.xml - i completely agree thats not the total solution for
> authorisation but it gives me a way to move forward now with current
> version of sculptor. Using that approach i can lock down flows as needed
> but more to the point I'm logically assigning some flows as being relevant
> particular roles (irrespective of what data content is visible).
>
> The example i gave was probably too simplistic but just say we had two
> different types of admin, one concerned with male persons and one with
> female persons. They both maybe needed to occasionaly look at detail of
> the opposite sex (so they are permitted to look at the other data) but in
> general they wanted a ListPerson to list only persons of the sex relevant
> to them. You see what I'm after is for a way to do the option like
>
> ListTask [male-admin] for Person { ..
> searchWith PersonService.findAllMales
>
>
> ListTask [female-admin] for Person { ..
> searchWith PersonService.findAllFemales
>
> as well as a 'default' for those users who aren't so 'focussed'
>
> ListTask for Person { ..
>
> A webapp may have all of the above available together and optionally to be
> used by any users as they see fit. This highlighting the point that a UI
> could be needed to expose multiple ways to want presentation of the same
> UI 'tasks' ie. sharing of control logic for different 'views.
>
> Another thought though to enable grouping of those 'related' tasks (eg. to
> enable simple generation of a male-admin menu as distinct from a female
> admin menu) would be to enable naming of multiple sculptor 'modules' be
> defined within a single 'gui' (at present it doesn't look like they can be
> named, just each being 'for' an underlying domain module). That could be a
> simplistic way to enable the generation and would be especially neat for
> partitioning the entire gui into role-relevant spaces.
>
> eg.
> Module male-admin for milkyway { ..
>
> ListTask for Person { ..
> searchWith PersonService.findAllMales
>
> Module female-admin for milkyway { ..
>
> ListTask for Person { ..
> searchWith PersonService.findAllFemales
>
> or maybe something similar could done up at defn of the 'gui' - though
> i'd expect that would tend to head us toward mutiple webapps as opposed to
> side-by-side modules inside a single webapp. Also obviously that last one
> could be achieved by simply defining multiple discrete gui's - which
> incidentally seems like the way i might head with this stuff in the
> short-term.
>
> Thanks heaps for your feedback guys - also should say the acegi/spring
> security will be great to have so pls don't misinterpret my comments
> above, just that my burning need is a way to re-use various UI tasks
>
>
>
>
>
>
>
>
> PaloT wrote:
>>
>> Some of my ideas:
>> - we have to consider supporting security on different levels:
>> - Service access (easy with Spring security and annotations or xml
>> config)
>> - Column access (read, write, search privileges)
>> - Row access (read, write, delete, create privileges)
>>
>> Row access:
>> Should be done in user code in services (find, save, ...).
>>
>> Column access:
>> With existing paging support isn't problem to simply nullify columns
>> in find service which can't be accessed by some users. I don't know if
>> hibernate somehow directly support this.
>>
>> My opinion is that you HAVE TO implement security on service tier not
>> VISUAL tier. Of course hiding columns for visualization purpose is
>> good feature.
>>
>> I guess you need "hint" feature also for Sculptor GUI because with:
>> ListTask for Person {
>> name.first
>> birthDate hints="role=admin, advisor"
>> ssn hints="role=advisor, accountant"
>> sex
>> }
>> and little tweak in SpecialCases you will be done ;-).
>>
>> Security is difficult because you can SLOW down your application too
>> much. That's why on this level is usually custom build.
>>
>> Regards
>>
>> Pavel
>>
>> 2010/4/21 Andreas Källberg <andreas.kallb...@gmail.com>:
>>> Hi,
>>> Nice suggestions, but you are a bit ahead of us here.
>>> There is plans for supporting authentication and authorization. When
>>> that is
>>> in place it would be nice to have dsl support for user roles.
>>> I guess it also could be possible to have multiple variations of tasks,
>>> i.e:
>>> ListTask for Person {
>>> name.first
>>> sex
>>> }
>>> ListTask [admin] for Person {
>>> name.first
>>> birthDate
>>> ssn
>>> sex
>>> }
>>>
>>> But it isn't something we have discussed
>>> If you feel it is something we should consider, think it through and add
>>> a
>>> suggestion in the tracker.
>>>
>>> .../Andreas
>>>
>>> On Wed, Apr 21, 2010 at 1:31 PM, greatfooty <greatfo...@gmail.com>
>>> wrote:
>>>>
>>>> I'm playing with setup of a sculptor site to contain multiple versions
>>>> of
>>>> various UI task-types (these to be invoked depending on auth role of
>>>> the
>>>> user).
>>>>
>>>> For example I'd want to define a 'public' ListTask for Person like
>>>> this:
>>>>
>>>> ListTask for Person {
>>>> name.first
>>>> sex
>>>> }
>>>>
>>>> and an 'admin' ListTask for Person like this:
>>>>
>>>> ListTask for Person {
>>>> name.first
>>>> birthDate
>>>> sex
>>>> ssn
>>>> }
>>>>
>>>> Thats a simple example and obviously i can achieve this particular one
>>>> by
>>>> doing say role-based suppression of output within the list_include.html
>>>> but
>>>> there can be many more complex examples where declarative definition in
>>>> the
>>>> DSL would be way easier.
>>>>
>>>> Is there already any way to do this? eg. maybe some hidden DSL options
>>>> for
>>>> naming tasks??
>>>>
>>>> --
>>>> View this message in context:
>>>> http://old.nabble.com/-Sculptor--Multiple-UI-tasks-per-%27task-type%27--tp28288008s17564p28288008.html
>>>> Sent from the Fornax-Platform mailing list archive at Nabble.com.
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> Fornax-developer mailing list
>>>> Fornax-developer@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/fornax-developer
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Fornax-developer mailing list
>>> Fornax-developer@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/fornax-developer
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Fornax-developer mailing list
>> Fornax-developer@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/fornax-developer
>>
>>
>
>
--
View this message in context:
http://old.nabble.com/-Sculptor--Multiple-UI-tasks-per-%27task-type%27--tp28288008s17564p28324281.html
Sent from the Fornax-Platform mailing list archive at Nabble.com.
------------------------------------------------------------------------------
_______________________________________________
Fornax-developer mailing list
Fornax-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fornax-developer
