(trunk) admin use cases

["J. Wolfgang Kaltz" <ka...@interactivesystems.info>]

I noticed group adding and deletion are already implemented as use 
cases, however the groups.xsl does not yet refer to them - I'll check 
that in right away, as the new use cases work. Accordingly the js 
functions are obsolete.

I have a question regarding the presentation of the admin area. When a 
use case is called, only the interface for that use case is rendered, 
and left-side navigation is not. Is that intentional ? Could it cause 
inconsistency problems if the user still has the left-side navigation, 
and clicks on something else, as opposed to clicking on either "submit" 
or "cancel" in the use case dialog ? I'm not yet familiar with the 
Cocoon continuations concepts, but I would suppose not completing a 
usecase at all must be allowed within creating an inconsistency.





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org

Re: (trunk) admin use cases

["Gregor J. Rothfuss" <gr...@apache.org>]

J. Wolfgang Kaltz wrote:
> I noticed group adding and deletion are already implemented as use 
> cases, however the groups.xsl does not yet refer to them - I'll check 
> that in right away, as the new use cases work. Accordingly the js 
> functions are obsolete.

+1

> I have a question regarding the presentation of the admin area. When a 
> use case is called, only the interface for that use case is rendered, 
> and left-side navigation is not. Is that intentional ? 

at the time, there were only full-screen usecases. we have since added 
support to have different view pipelines (eg for the tab usecases). the 
same approach might be in order here.

> Could it cause 
> inconsistency problems if the user still has the left-side navigation, 
> and clicks on something else, as opposed to clicking on either "submit" 
> or "cancel" in the use case dialog ? I'm not yet familiar with the 
> Cocoon continuations concepts, but I would suppose not completing a 
> usecase at all must be allowed within creating an inconsistency.

right. as long as nothing happens in the setup of the usecase that has 
side-effects.


-- 
Gregor J. Rothfuss
COO, Wyona       Content Management Solutions    http://wyona.com
Apache Lenya                              http://lenya.apache.org
gregor.rothfuss@wyona.com                       gregor@apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org

Re: (trunk) admin use cases

[Andreas Hartmann <an...@apache.org>]

J. Wolfgang Kaltz wrote:
> I noticed group adding and deletion are already implemented as use 
> cases, however the groups.xsl does not yet refer to them - I'll check 
> that in right away, as the new use cases work. Accordingly the js 
> functions are obsolete.
> 
> I have a question regarding the presentation of the admin area. When a 
> use case is called, only the interface for that use case is rendered, 
> and left-side navigation is not. Is that intentional ?

No, it's just not yet implemented.


> Could it cause 
> inconsistency problems if the user still has the left-side navigation, 

Actually that should be no problem. The usecase framework should support
transactions (well, that's not quite finished, the UnitOfWork and related
classes have to be extended with transactional functionality). Then it
shouldn't cause inconsistencies when the usecase is interrupted.


> and clicks on something else, as opposed to clicking on either "submit" 
> or "cancel" in the use case dialog ? I'm not yet familiar with the 
> Cocoon continuations concepts, but I would suppose not completing a 
> usecase at all must be allowed within creating an inconsistency.

Yes, definitely (I guess you mean "without").

It's good to see that you make yourself familiar with the
usecase framework. I'm looking forward to more hints :)

-- Andreas


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org