infinite loop in pipeline processing

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

Hi all,
I triggered an infinite loop in the pipeline processing, by accidently 
directly accessing an (invalid) URL. This happens in 1_2_X and trunk.

There are "default/admin" and "default/admin/users/someuser.html" which 
are valid URLs in the default publication.
However, requesting "default/admin/users" results (according to the log) 
in sitemap parameters

"internal/users" and "default/admin/sitetree/internal/users.xml"
then (down the road)

"internal/internal/users" and 
"default/admin/sitetree/internal/internal/user.xml"

and so on until memory is out.

This is probably true of some other illegal URLs as well. Of course one 
could say "well then don't request that URL if it hurts" :) But I think 
this is actually a serious problem worth tracking down.

I'm looking at the admin.xmap sitemap but can't figure out where the 
loop is occurring.

Any ideas ?

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

Re: usecase framework / navigation

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

J. Wolfgang Kaltz wrote:
> Andreas Hartmann schrieb:

[...]

> If I understand correctly, in the site (that is, info-authoring) area, 
> navigation is already a usecase. That is, user clicking on site triggers 
> the use case "show all available use cases for site, that is, meta, 
> assets, versions etc.". This use case is called "tab" (which BTW is not 
> a good wording, as it just names the GUI pattern, instead of what it 
> achieves).

In this case, the prefix actually is related to the tabbed display style.
In usecase.xmap, the view style is determined using the "tab." prefix.
If we find a better way to achieve this, we could use arbitrary
usecase names for the site area (workflow.history, rc.viewRevisions etc.)


> So I suppose that for the "admin" area we want to implement a 
> similar overview use-case, which would lead to the various admin 
> use-cases ?

I guess that would be a good idea.


> What I am wondering is, how far this idea of using use-cases to 
> implement navigation should go. Because if we take the idea of the site 
> navigation ("tab" usecase) further, the whole navigation would become 
> use cases. That would mean, in the admin/authoring area, after the login 
> usecase, the user is presented with the list of possible use cases. How 
> it is rendered is a different issue of course. If she chooses the 
> use-case "show admin use-cases", she is taken to the next step, i.e. 
> shown the available use-cases in admin area.
> 
> The same issue holds for the live website navigation. It might be 
> helpful to reflect upon website navigation as a usecase as well, I don't 
> know. I'm thinking roles, that is which user may see what, and perhaps 
> even (for the future) adapting the page to some situation, i.e. which 
> parts are shown in which situation. Since some hooks for logic are 
> needed anyway when delivering content in the live website, it might make 
> sense to think in terms of usecase framework.

Wow, that would be a big change ...
I have to think a little bit more about it.


> In any case, what is not so good at the moment in the 
> admin/site/authoring stuff, is that navigation concepts are entirely 
> different in each area.

Yes, I agree. Actually the admin area depends on a sitetree
as well, so authoring and admin are kind-of similar.


> Admin is html navigation, site via use-cases, 
> and authoring via menus. I think we should find a consistent navigation 
> strategy (at least for the non-live parts). I'm not sure ATM which 
> approach is best, but they definitely should be consistent. WDYT ?

Maybe you can write a RT/proposal about that? IMO it is very interesting.


-- Andreas


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

Re: usecase framework / navigation

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

Andreas Hartmann schrieb:
>> (...)
>> I am wondering if and how this should transferred to the usecase 
>> framework. Would this be the "View available group-related usecases" 
>> usecase, with isInteractive set to false ?
> 
> 
> Actually I didn't yet think about that. I saw a usecase as a user
> interaction scenario as well, but that can be interpreted in many ways :)
> 
> The implementation of plain views (e.g., the overview screens in the
> admin area) is very simple using usecases. You just have to write
> a little bit of Java to create the model and a JX template to present it.
> 
> I think it's fine with me to use the usecase framework for this purpose.
> 
>> So in essence, the navigation itself would be use-cases ? (at least in 
>> authoring, not sure about live)
> 
> 
> Do you mean the website navigation? Could you explain a bit more?

If I understand correctly, in the site (that is, info-authoring) area, 
navigation is already a usecase. That is, user clicking on site triggers 
the use case "show all available use cases for site, that is, meta, 
assets, versions etc.". This use case is called "tab" (which BTW is not 
a good wording, as it just names the GUI pattern, instead of what it 
achieves). So I suppose that for the "admin" area we want to implement a 
similar overview use-case, which would lead to the various admin use-cases ?

What I am wondering is, how far this idea of using use-cases to 
implement navigation should go. Because if we take the idea of the site 
navigation ("tab" usecase) further, the whole navigation would become 
use cases. That would mean, in the admin/authoring area, after the login 
usecase, the user is presented with the list of possible use cases. How 
it is rendered is a different issue of course. If she chooses the 
use-case "show admin use-cases", she is taken to the next step, i.e. 
shown the available use-cases in admin area.

The same issue holds for the live website navigation. It might be 
helpful to reflect upon website navigation as a usecase as well, I don't 
know. I'm thinking roles, that is which user may see what, and perhaps 
even (for the future) adapting the page to some situation, i.e. which 
parts are shown in which situation. Since some hooks for logic are 
needed anyway when delivering content in the live website, it might make 
sense to think in terms of usecase framework.

In any case, what is not so good at the moment in the 
admin/site/authoring stuff, is that navigation concepts are entirely 
different in each area. Admin is html navigation, site via use-cases, 
and authoring via menus. I think we should find a consistent navigation 
strategy (at least for the non-live parts). I'm not sure ATM which 
approach is best, but they definitely should be consistent. WDYT ?




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

Re: usecase framework (Was: Re: infinite loop in pipeline processing)

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

J. Wolfgang Kaltz wrote:
> Gregor J. Rothfuss schrieb:
> 
>> (...)
>> this will likely go away with the migration of the remaining admin 
>> usecases to uc fw. the problem seems to be in a view pipeline.
>>
> 
> This raises YAIQ (yet another interesting question) regarding the goal 
> of the use case framework: so far I've understood a use case to 
> represent a single user interaction scenario, e.g. "Add a group" -> this 
> results in a form and usually a second step to confirm or cancel changes.
> It would of course be nice to have for the complete admin & authoring 
> area a unifying approach. Right now, if an admin clicks on "groups", 
> groups.xsp is executed to generate the XML list of groups, which is then 
> rendered by groups.xsl. That XSL contains links to the group usecases, 
> via the form buttons.
> 
> I am wondering if and how this should transferred to the usecase 
> framework. Would this be the "View available group-related usecases" 
> usecase, with isInteractive set to false ?

Actually I didn't yet think about that. I saw a usecase as a user
interaction scenario as well, but that can be interpreted in many ways :)

The implementation of plain views (e.g., the overview screens in the
admin area) is very simple using usecases. You just have to write
a little bit of Java to create the model and a JX template to present it.

I think it's fine with me to use the usecase framework for this purpose.

> So in essence, the navigation 
> itself would be use-cases ? (at least in authoring, not sure about live)

Do you mean the website navigation? Could you explain a bit more?

> In general, should one usecase potentially lead to N other usecases ?

IMO that should be possible.

> Probably, though I am not sure of the implications, especially in 
> interactive use cases.

A condition would be that a usecase can be cancelled at any stage
without side effects and implications on the model, but this
transactional behaviour has to be solved anyway.

-- Andreas


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

usecase framework (Was: Re: infinite loop in pipeline processing)

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

Gregor J. Rothfuss schrieb:
> (...)
> this will likely go away with the migration of the remaining admin 
> usecases to uc fw. the problem seems to be in a view pipeline.
> 

This raises YAIQ (yet another interesting question) regarding the goal 
of the use case framework: so far I've understood a use case to 
represent a single user interaction scenario, e.g. "Add a group" -> this 
results in a form and usually a second step to confirm or cancel changes.
It would of course be nice to have for the complete admin & authoring 
area a unifying approach. Right now, if an admin clicks on "groups", 
groups.xsp is executed to generate the XML list of groups, which is then 
rendered by groups.xsl. That XSL contains links to the group usecases, 
via the form buttons.

I am wondering if and how this should transferred to the usecase 
framework. Would this be the "View available group-related usecases" 
usecase, with isInteractive set to false ? So in essence, the navigation 
itself would be use-cases ? (at least in authoring, not sure about live)

In general, should one usecase potentially lead to N other usecases ? 
Probably, though I am not sure of the implications, especially in 
interactive use cases.




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

Re: infinite loop in pipeline processing

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

J. Wolfgang Kaltz wrote:
> Hi all,
> I triggered an infinite loop in the pipeline processing, by accidently 
> directly accessing an (invalid) URL. This happens in 1_2_X and trunk.
> 
> There are "default/admin" and "default/admin/users/someuser.html" which 
> are valid URLs in the default publication.
> However, requesting "default/admin/users" results (according to the log) 
> in sitemap parameters
> 
> "internal/users" and "default/admin/sitetree/internal/users.xml"
> then (down the road)
> 
> "internal/internal/users" and 
> "default/admin/sitetree/internal/internal/user.xml"
> 
> and so on until memory is out.

this will likely go away with the migration of the remaining admin 
usecases to uc fw. the problem seems to be in a view pipeline.

-- 
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