As discussed in various threads we need a common environment model for
flow, templating (both with flow and non-flow input). And it will also
make Cocoon easier to learn if the environment part of FOM (let us call
it OM) and the sitemap environment model, i.e. input modules (IMs) are
put togeth
Daniel Fagerstrom wrote:
API
---
OM is a Map. IMs are like maps but have both construction and runtime
configurations and also interpret the "key" in much more sofisticated
ways than maps normally do.
WDYT?
/Daniel
Wow. Cocoon already has an ObjectModel Map which is used all over the
place. I
Daniel Fagerstrom wrote:
As discussed in various threads we need a common environment model for
flow, templating (both with flow and non-flow input). And it will also
make Cocoon easier to learn if the environment part of FOM (let us call
it OM) and the sitemap environment model, i.e. input modu
Ralph Goers wrote:
Daniel Fagerstrom wrote:
API
---
OM is a Map. IMs are like maps but have both construction and runtime
configurations and also interpret the "key" in much more sofisticated
ways than maps normally do.
WDYT?
/Daniel
Wow. Cocoon already has an ObjectModel Map which is used all
Gregor J. Rothfuss wrote:
Daniel Fagerstrom wrote:
As discussed in various threads we need a common environment model
for flow, templating (both with flow and non-flow input). And it will
also make Cocoon easier to learn if the environment part of FOM (let
us call it OM) and the sitemap environm
On Tue, 01 Mar 2005 11:33:32 +0100, Daniel Fagerstrom
<[EMAIL PROTECTED]> wrote:
> Gregor J. Rothfuss wrote:
>
> > Daniel Fagerstrom wrote:
> >
> >> As discussed in various threads we need a common environment model
> >> for flow, templating (both with flow and non-flow input). And it will
> >> al
Peter Hunsberger wrote:
On Tue, 01 Mar 2005 11:33:32 +0100, Daniel Fagerstrom
<[EMAIL PROTECTED]> wrote:
Gregor J. Rothfuss wrote:
Daniel Fagerstrom wrote:
As discussed in various threads we need a common environment model
for flow, templating (both with flow and non-flow input). And
On Wed, 02 Mar 2005 18:14:56 +0100, Daniel Fagerstrom
<[EMAIL PROTECTED]> wrote:
> Peter Hunsberger wrote:
>
> >On Tue, 01 Mar 2005 11:33:32 +0100, Daniel Fagerstrom
> ><[EMAIL PROTECTED]> wrote:
> >
> >
> >>Gregor J. Rothfuss wrote:
> >>
> >>
> >>>Daniel Fagerstrom wrote:
> >>>
> >>>
> As dis
Peter Hunsberger wrote:
On Wed, 02 Mar 2005 18:14:56 +0100, Daniel Fagerstrom
<[EMAIL PROTECTED]> wrote:
Peter Hunsberger wrote:
On Tue, 01 Mar 2005 11:33:32 +0100, Daniel Fagerstrom
<[EMAIL PROTECTED]> wrote:
Gregor J. Rothfuss wrote:
Daniel Fagerstrom wrote:
As
On Wed, 02 Mar 2005 20:51:13 +0100, Daniel Fagerstrom
<[EMAIL PROTECTED]> wrote:
> Peter Hunsberger wrote:
>
> >On Wed, 02 Mar 2005 18:14:56 +0100, Daniel Fagerstrom
> ><[EMAIL PROTECTED]> wrote:
> >
> >
> >>Peter Hunsberger wrote:
> >>
> >>
> >>>On Tue, 01 Mar 2005 11:33:32 +0100, Daniel Fagerstr
Peter Hunsberger wrote:
On Wed, 02 Mar 2005 20:51:13 +0100, Daniel Fagerstrom
<[EMAIL PROTECTED]> wrote:
Peter Hunsberger wrote:
On Wed, 02 Mar 2005 18:14:56 +0100, Daniel Fagerstrom
<[EMAIL PROTECTED]> wrote:
Peter Hunsberger wrote:
On Tue, 01 Mar 2005 11:33:32 +0100, Daniel Fagerstrom
<[EMAIL PRO
Daniel Fagerstrom wrote:
So the innocent looking i/o modules give us a quite a number of problems
if we want to build an OM from them.
Yes, I agree.
So what do I propose instead? If we think of it the only thing we need
is access to objects (and preferably script (SL) and expression language
(E
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
So the innocent looking i/o modules give us a quite a number of
problems if we want to build an OM from them.
Yes, I agree.
So what do I propose instead? If we think of it the only thing we
need is access to objects (and preferably script (SL) and
Daniel Fagerstrom wrote:
> Carsten Ziegeler wrote:
>
>>Hmm, I can't help myself but this interface looks a little bit too
>>simple for me :)
>
>
> So you have no suggestions about how to remove the remaining fat from
> the interface :)
>
:)
> More seriously, take a look at e.g. the FlowAttri
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
Ok, ehm, let's start with the simple interface :)
Yes, one thing at a time, if we do all the fun stuff now, we will not
have anything to do in the future ;)
All we need is a
better name...
I have thought about things like
[Environment|Context|Scr
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
So the innocent looking i/o modules give us a quite a number of
problems if we want to build an OM from them.
Yes, I agree.
So what do I propose instead? If we think of it the only thing we
need is access to objects (and preferably script (SL) and
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
So the innocent looking i/o modules give us a quite a number of
problems if we want to build an OM from them.
Yes, I agree.
So what do I propose instead? If we think of it the only thing we
need is access to objects (and pref
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>
>
> Sorry, I should have missed something. What is the purpose of a service
> interface that just returns an object. Why isn't this object the
> component itself? Just like the current OM contains the request and
> response objects, and not pro
Daniel Fagerstrom wrote:
The important thing for the "modules" is to provide script friendly
access of environment data in a simple way. I assumed that the easiest
way would be to support "POJO" interfaces with get and set methods and
Maps so that it would be easy to use for the reflection parts
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sorry, I should have missed something. What is the purpose of a service
interface that just returns an object. Why isn't this object the
component itself? Just like the current OM contains the request and
response objects,
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
So the innocent looking i/o modules give us a quite a number of
problems if we want to build an OM from them.
Yes, I agree.
So what do I propose instead? If we think of it the only thing we
need is ac
Sylvain Wallez wrote:
> So in essence, the get() method on object model, which can be a special
> subclass of HashMap would be:
>
> Object get(Object name) {
> // call the regular Map get method
> Object result = super.get(name);
> if (result instanceof Module) {
> // Derefere
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
The important thing for the "modules" is to provide script friendly
access of environment data in a simple way. I assumed that the
easiest way would be to support "POJO" interfaces with get and set
methods and Maps so that it would be easy to use f
Daniel Fagerstrom wrote:
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
The important thing for the "modules" is to provide script friendly
access of environment data in a simple way. I assumed that the
easiest way would be to support "POJO" interfaces with get and set
methods and Maps so that
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Don't think so (returning an Object does not to restrict things that
much ;) ), but I haven't thought in detail about all modules, any
examples where it wouldn't work?
E.g. those modules that do some xpath extraction on XML da
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
The important thing for the "modules" is to provide script friendly
access of environment data in a simple way. I assumed that the
easiest way would be to support "POJO" interfaces with get and set
met
Carsten Ziegeler wrote:
interface Module {
String ROLE = Module.class.getName();
Object getObject();
}
Hmm, I can't help myself but this interface looks a little bit too
simple for me :)
Carsten
I guess I still don't see why this is needed. Why would we implement this:
Request request =
Ralph Goers wrote:
> What exactly is this interface buying us again?
>
I think you missunderstood the idea, so I will try to explain it:
Currently, the objects available in the object model are hard-coded, you
can get a request object, a response object and some more. So something like
objectMod
Carsten Ziegeler wrote:
Ralph Goers wrote:
What exactly is this interface buying us again?
I think you missunderstood the idea, so I will try to explain it:
Currently, the objects available in the object model are hard-coded, you
can get a request object, a response object and some more. So
Ralph Goers wrote:
> Carsten Ziegeler wrote:
>
>
> OK. I'm not sure I'd try to solve the problem that way though. I'd
> probably just use the existing object model. Since its a Map I can put
> anything I want into it. To get at things I'd just put objects in the
> map to get them like:
> o
Carsten Ziegeler wrote:
Ralph Goers wrote:
Carsten Ziegeler wrote:
OK. I'm not sure I'd try to solve the problem that way though. I'd
probably just use the existing object model. Since its a Map I can put
anything I want into it. To get at things I'd just put objects in the
map to get the
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Vadim Gritsenko wrote:
Into POJO / Maps, EL friendly interface:
context.getRequestParameterMap()
context.getRequestMap()
context.getSessionMap()
context.getApplicationMap()
Having something like that (parameters/attribu
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Isn't it too restrictive compared to the variety of what modules do?
Don't think so (returning an Object does not to restrict things that
much ;) ), but I haven't thought in detail about all modules, any
examples where it would
Vadim Gritsenko wrote:
>
> IMHO, there is no point in such input modules anymore. All you need is
>
>* JS and EL firendly object model with "object factories"
> ("modules" is banned word)
>
>* Support of the EL in the sitemap
>
> Once these two points are here, all existing input
Le 4 mars 05, à 05:27, Vadim Gritsenko a écrit :
...Once these two points are here, all existing input modules can be
(deprecated and) removed. And all that they did can be then done in
the sitemap with EL:
{/request/attributes/user}
WDYT?
Way cool!
-Bertrand
smime.p7s
Description: S/MIME cr
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Isn't it too restrictive compared to the variety of what modules do?
Don't think so (returning an Object does not to restrict things that
much ;) ), but I haven't thought in detail about all modules, any
Vadim Gritsenko wrote:
IMHO, there is no point in such input modules anymore. All you need is
* JS and EL firendly object model with "object factories"
("modules" is banned word)
* Support of the EL in the sitemap
Once these two points are here, all existing input modules can be (deprec
On Fri, 04 Mar 2005 10:10:05 +0100, Sylvain Wallez <[EMAIL PROTECTED]> wrote:
> Vadim Gritsenko wrote:
>
> > Sylvain Wallez wrote:
> >
> >> Daniel Fagerstrom wrote:
> >>
> >>> Sylvain Wallez wrote:
> >>>
> Isn't it too restrictive compared to the variety of what modules do?
> >>>
> >>> Don't
Peter Hunsberger wrote:
This is more of a RT than anything concrete for or against the ideas
given so far.
As I follow this discussion it keeps striking me that we're
more-or-less reinventing resolvers and sources at a slightly lower
level. At one level, people need:
protocol://x/y/z
to resolv
On Sat, 05 Mar 2005 11:52:58 +0100, Daniel Fagerstrom
<[EMAIL PROTECTED]> wrote:
> Peter Hunsberger wrote:
>
> > This is more of a RT than anything concrete for or against the ideas
> > given so far.
> >
> > As I follow this discussion it keeps striking me that we're
> > more-or-less reinventing r
Peter Hunsberger wrote:
On Sat, 05 Mar 2005 11:52:58 +0100, Daniel Fagerstrom
<[EMAIL PROTECTED]> wrote:
Peter Hunsberger wrote:
This is more of a RT than anything concrete for or against the ideas
given so far.
As I follow this discussion it keeps striking me that we're
more-or-less reinv
On Mon, 07 Mar 2005 19:19:24 +0100, Daniel Fagerstrom
<[EMAIL PROTECTED]> wrote:
> Peter Hunsberger wrote:
older conversation
>
> >>>
> >>>
> >>Sources are designed for giving access to streams (and due to eficciency
> >>reasons SAX streams) and the "object accessors" are intended to give
> >>acc
Peter Hunsberger wrote:
On Mon, 07 Mar 2005 19:19:24 +0100, Daniel Fagerstrom
<[EMAIL PROTECTED]> wrote:
Peter Hunsberger wrote:
That's not a use case, that's a technical usage example (at best).
We've already got unified access to environment data like the request
object. For example, the Req
On Mon, 07 Mar 2005 20:56:42 +0100, Daniel Fagerstrom
<[EMAIL PROTECTED]> wrote:
> Peter Hunsberger wrote:
>
> >On Mon, 07 Mar 2005 19:19:24 +0100, Daniel Fagerstrom
> ><[EMAIL PROTECTED]> wrote:
> >
> >
> >>Peter Hunsberger wrote:
> >>
>
>
> >That's not a use case, that's a technical usage exam
Peter Hunsberger wrote:
On Mon, 07 Mar 2005 20:56:42 +0100, Daniel Fagerstrom
<[EMAIL PROTECTED]> wrote:
Peter Hunsberger wrote:
On Mon, 07 Mar 2005 19:19:24 +0100, Daniel Fagerstrom
<[EMAIL PROTECTED]> wrote:
Peter Hunsberger wrote:
That's not a use case, that's a tec
Daniel Fagerstrom wrote:
> Are you refering to the idea of having a configurable OM? I found it
> initially to be FS, but everybody else that was involved in the
> discussion wanted it, so I based my proposal on it. Carsten wanted it
> for giving access to some portal specific data for portal us
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
Are you refering to the idea of having a configurable OM? I found it
initially to be FS, but everybody else that was involved in the
discussion wanted it, so I based my proposal on it. Carsten wanted it
for giving access to some portal specific
Daniel Fagerstrom wrote:
AFAIK there is no existing xpath traversal machinery in Cocoon that we
could reuse.
JFYI,
Vadim
Ralph Goers wrote:
Vadim Gritsenko wrote:
IMHO, there is no point in such input modules anymore. All you need is
* JS and EL firendly object model with "object factories"
("modules" is banned word)
* Support of the EL in the sitemap
Once these two points are here, all existing input module
49 matches
Mail list logo
