Concept of

[kamikatze]

Is there a concept of perspectives (like in eclipse) in nukes?

I think of changing the whole block arrangements and visibility dynamically in a module.

The background is, I'm currently working on a shop module with a couple of blocks (product categories, manufacturers, latest product, shopping cart, special offer, customers who bought this also bought that... etc)
These blocks only makes sense to the user of the site if he navigates to the shop module.

It is possible anyhow, to change the blocks like it is done in the BlocksModule, but I don't want these changes to be persistet in any sense and I want to have the changes reverted when the user navigates out of the shop context.

Has anyone thought about such a feature and if not, what is your opinion of having such a concept of a perspective in nukes?

[julien1]

you mean to have different views, for instance :

view #1 contains : forums, html block 1, html block 2
view #2 contains : news, html block 3
etc...

and the url could be something like : index.html?view=1

[kamikatze]

Yep,

there's the contextual html block already, but contrary to making the visibility dependant on the directory of the html-module only, we could put a interceptor in the control flow that would not only change the visibility, but the position of a module as well. And that dependant on such a view parameter.

A question going further would be, can a logged in user customize the view (collapse or even change visibility/position of blocks). But that is not a prerequisite for the shop.

[kamikatze]

"KaMiKaTze" wrote:
...but the position of a module as well.

the position of a block, I mean.

[julien1]

This is something I want to change in Nukes 2. Yes it is design around the concept of reified invocation (to use marc's favourite expression :-) ) and the view should be constructed by an Interceptor and put in the Invocation object by it so the dispatch Interceptor uses it. It allows to swap implementation easily.

Now for the concrete thing, there are several ways to do that, the way it is done today in Nukes 1.x is :

target = get the target module (or default if no specified)
get all the blocks
filters the blocks that should not be rendered
compute everything

that's a bit primitive and does not give much flexibility for some site designs. I don't want to spend a lot of time on that for Nukes 2.0 alpha/beta releases so it mayby still the same view or something simple with a set of Pages that aggregate components. But the design will allow to change it later easily.

[kamikatze]

Where would you put that in (in 1.1)?

Are the blocks render() methods called before the module's operation then it wouldn't be a good idea to do it there as it would waste cpu ressources to render first and dispose then. On top of that it would prohibit the addition of blocks.

What is the state of 2.0? Does it make sense to target 2.0 for my work? Currently I'm using the cvs head (ok, about 7 days old).
I'd be interested in helping to code the views.

[kamikatze]

To implement the views, would the strategy be

to stop and start (as MBean-Server invocation) the blocks
or to intercept the render method for nonvisible blocks but keep them running.

[julien1]

I think the best would be to intercept before dispatching and remove the block not needed.

[kamikatze]

I still try to get my head around how it best would be done. Block's process() methods are called from the org.jboss.nukes.core.Main class. Would you suggest to continue calling the process() methods and just omit the output in an interceptor, or would you think to hook in at this point and omit even the call to process?