Re: WishFull thinking JX and SessionContext Authentication

Sat, 22 Jan 2005 07:50:44 -0800

Leszek Gawron wrote:
Leszek Gawron wrote:
Carsten Ziegeler wrote:
Leszek Gawron wrote:
Carsten Ziegeler wrote: 
oceatoon wrote:

This is wishfull thinking and probably no news to those refactoring JX. But
access to the session context object like the session-context input module
would be great (like for example with the authentication context). I have
found other post asking about and for this sort of functionality. it would
smoothen quite a bit the access to such inportant elements as the ones in
session-context (like authentication data).

Yes, this should be possible, I agree. I hope that the refactored version will be pluggable to plug-in some kind of adapter to access "own data" like the authentication context etc.

You don't need to just hope, you can either implement it or describe how it should work so that someone else can do it ;)

Then I think that it shouldn't be part of the JXTG code but rather part of the TemplateObjectModelHelper or some supporting classes, that in turn are used by JXTG. This way it could be used outside JXTG.

Wouldn't it be better if JXTG supported input modules with syntax like:

{im:moduleName:valueName}

Don't know if I like that, modules and expressions are a little bit overlapping as many modules are using JXPath. The question is who should call who. And I'm not certain that:

{im:flow-attr:jexl:foo.bar}

would help making Cocoon easy to use and understand ;)

Don't know :) Sure, this is one solution - my idea is a little bit different:
we could provide a pluggable object model and then use this object model in jxtg,
but also in input modules - so in fact you would only need one input module and can use the same syntax there as in jxtg. I'm not sure if this makes sense, but if it does, we wouldn't need input modules anymore. 

>>> Carsten

Makes sense to me, I would also prefer going this direction. Having one prefered way to access things and using it everywhere will make Cocoon easier to learn. And we can focus our work on one implementation.

We need to identify which modules that give access to something that not allready is part of FOM and discuss which of them that we want to make accessable from FOM.

Then we could put all the module in a block and thus get rid of the most exotic (mis)uses of the module concept from core.

Maybe we could make the FOM pluggable so that we have a configuration where one decides what object that shoud be part of FOM.

Then on the other hand we shouldn't overdo it. More specialized pluging can always be done in flow:

don't we have a pluggable object model ? :))

function doIt() {
  var objectModel = {};

  objectModel.pluggedIn1 = entityFromDatabase();
  objectModel.pluggedIn2 = request.getParameter( "skin" );

  cocoon.sendPage( "view/myview.jx", objectModel );
}


I would go further:

function doIt() {
  var objectModel = {};

  objectModel.pluggedIn1 = entityFromDatabase();
  objectModel.pluggedIn2 = request.getParameter( "skin" );

  return objectModel;
}

<match pattern="foo">
  <call function="doIt"/>
  <generate type="jx" src="foo"/>
  ...
</match>

Or whatever syntax we choose for (flow)script actions. The idea is that the flow context is the return value from the function.

I'll start to discuss design and work on this after the JXTG refactoring if no one else does it before me and if the community agrees.

Other data that is not directly available from flow (like authentication context can be accessed with input modules that are already available).

something like this in flow would be useful:

function doIt() {
  var objectModel = {
      skin: cocoon.inputModule.defaults.getValue( "skin" )};

  cocoon.sendPage( "view/myview.jx", objectModel );

that would require FOM to be extended. WDYT?

IIRC modules was part of flow once but removed after a vote as people thought that most of the things you can do with modules can be done in a less clumsy way with the FOM and ordinary JS constructs and that where was no reason do duplicate functionality.

I would prefer to do as outlined above, identify what or maybe if we are missing something from some input modules and make that functionality available in $cocoon or through flow.

/Daniel

Reply via email to