Re: [SourceResolver] getLastModified() for cocoon:// sources always returns 0

2003-06-23 Thread Stefano Mazzocchi
on 6/22/03 3:32 PM Christopher Oliver wrote:

> In Linotype I saw some other strange uses of the cocoon:// protocol that 
> appear to be very bad for performance:
> There's a pipeline that uses the directory generator to read a 
> directory, and transforms it using xslt into a cinclude template. 
> Another pipeline uses this as a source for its generator using the 
> cocoon:// protocol. This would seem to defeat any possibility of 
> compiling the cinclude template (or am I missing something?)

No, you are totally right: linotype is *very* inefficient from an
algorithmical perspective.

In fact, linotype does need a database if we want it to scale. I'm
planning to keep an eye on JSR-170 (Repository API) and the Slide
implementation for it.

right now, linotype is just a proof of concept to show how things can be
done quick and dirty and still be rather powerful and useable. Also to
show how powerful a few tens of Kb of javascript code spread across teh
client and server can be.

Also, it's a try to test the darwinistic development principles of
"start with the little design as possible": seed first, incrementally
improve the system.

Will it work? I don't know, but it's worth trying, expecially in a great
community like Cocoon's, there is a lot of ecosystem power and plenty of
social noise to feed the system and see what happens.

-- 
Stefano.




RE: [SourceResolver] getLastModified() for cocoon:// sources always returns 0

2003-06-23 Thread Reinhard Pötz

> From: Christopher Oliver [mailto:[EMAIL PROTECTED] 
> 
> You're right. But it's a bad idea to use the cocoon:// 
> protocol as the 
> source for JXTemplateGenerator (as it would be also for 
> TraxTransformer, 
> for example). In effect you are generating a new "program" for every 
> request, that must be recompiled for every request, which is clearly 
> _very_ inefficient. Perhaps caching could fix this in some 
> cases, but it 
> seems like a bad practice in the first place.

Not in my use case. I use "datasource" pipelines that provide raw data
only instead of objects. I'm aware that those parts can't be compiled
but I'm completly satisfied if the Cocoon internal caching mechanism
works. I'll check why source.getValidity() doesn't work for me with the
latest CVS.

Reinhard



RE: [SourceResolver] getLastModified() for cocoon:// sources always returns 0

2003-06-23 Thread Reinhard Pötz
> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
> 
> Reinhard Pötz wrote:
> >
> >
> > If I understand this correctly I get with
> >
> > source.getValidity()
> >
> > the SourceValidity.
> Yes.
> 
> > But if I call e.g. cocoon://blablalba.xml this
> > method returns null. The default pipe is the caching pipe and I use 
> > it with
> >
> > 
> > ...
> > 
> >
> > If I resolve a resource using the file protocol a SourceValidity
> > object is returned.
> >
> > Do I have to change something to get a SourceValidity
> object returned
> > from a cocoon source?
> >
> No, this should work (and it worked some weeks ago :) )
> 
> So, if I understand you correctly, you're using the lastest
> 2.1-dev, use the SourceResolver to resolve 
> "cocoon://blablalba.xml", get a o.a.e.source.Source object 
> and when you call getValidity(), you get "null" as the result?

I used 2.1-dev-M2. I going to set up a test example using the latest CVS
snapshot and report if it works for me.

Reinhard 



RE: [SourceResolver] getLastModified() for cocoon:// sources always returns 0

2003-06-23 Thread Carsten Ziegeler
Reinhard Pötz wrote:
>
>
> If I understand this correctly I get with
>
> source.getValidity()
>
> the SourceValidity.
Yes.

> But if I call e.g. cocoon://blablalba.xml this
> method returns null. The default pipe is the caching pipe
> and I use it with
>
> 
> ...
> 
>
> If I resolve a resource using the file protocol a SourceValidity object
> is returned.
>
> Do I have to change something to get a SourceValidity object returned
> from a cocoon source?
>
No, this should work (and it worked some weeks ago :) )

So, if I understand you correctly, you're using the lastest 2.1-dev,
use the SourceResolver to resolve "cocoon://blablalba.xml", get
a o.a.e.source.Source object and when you call getValidity(), you
get "null" as the result?

Carsten



RE: [SourceResolver] getLastModified() for cocoon:// sources always returns 0

2003-06-20 Thread Reinhard Pötz


> From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
> 
> 
> Reinhard Pötz wrote:
> 
> >If I call the method getLastModified() for cocoon://
> >sources the return value is always 0. Is this the 
> >correct behaviour?
> >
> 
> Yes !
> 
> >If yes at least the JXTemplateGenerator (line 2868) 
> >doesn't work correctly and I think some more components too.
> >
> 
> Didn't look at it, but 2.1 components should rely on 
> Excalibur Sources 
> and the associated SourceResolver (looked up in the component 
> manager) 
> to use the Source's validity.

Thank you!

If I understand this correctly I get with

source.getValidity()

the SourceValidity. But if I call e.g. cocoon://blablalba.xml this
method returns null. The default pipe is the caching pipe
and I use it with


...


If I resolve a resource using the file protocol a SourceValidity object
is returned.

Do I have to change something to get a SourceValidity object returned
from a cocoon source?

Reinhard