cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <nicola...@supereva.it>
Subject Re: [C2]Access control using sitemap
Date Wed, 13 Sep 2000 12:01:11 GMT
----- Original Message ----- 
From: "Giacomo Pati" <pati_giacomo@yahoo.com>
To: <cocoon-dev@xml.apache.org>; <thezvi@ifrance.com>
Sent: Wednesday, September 13, 2000 10:42 AM
Subject: Re: [C2]Access control using sitemap


> 
> --- Zvi <thezvi@ifrance.com> wrote:
> > Hi Giacomo,
> > 
> > I finally  got your example,
> > you using custom transformer, which trasforms and include specified
> > document in
> > the position specified by parameter.
> > Except that this require to write custom transformer. 
> 
> What's wrong with writing custom transformers? You said you use XSP and
> this is writing a custom sitemap component anyway. A transformer is in
> no way only applying a stylesheet using XSLT. Many weeks ago there was
> a discussion about using XSP to write custom transormers and I think
> Ricardo has take this need seriously into account by it's design of the
> new C2 XSP engine (it's not able to do it now but C2 is still a moving
> target so anything may happen).

I am writing a system for writung Transformers "like" XSP, being
able to use XSP taglibs; I've said something to Stefano but it's really
to early to be more precise.
I know a promise is _just a promise_ but I seriously think it's possible.
I've written the class that will be extended by the XTP files (eXtensible
Transformation Pages), it works, and I'm studying code from the sitemap and
XSPs to see how code generation is done.
I write this only to inform you all and especially Ricardo of my efforts.
I'm in the middle of my September exam session but hope to have a 
rough implementation ready in 2-3 weeks' time.
The abstract class BTW, is easy to use in Transformer creation, if
you are interested I can send you.
I used it in the chart creation Transformers I'm polishing up.

> > It's also
> > wasting
> > performance.
> 
> C'mon, where does my example waste more CPU cycles that yours? Do you
> agree that both examples needs to generate the included XSP sitebars?
> But your example additionally wants to cache the SAX event produced by
> an XSP page which already _is_ a cached form of SAX events.
> 
> > What I mean, by my first example is:
> > 1. Transform sitebar.xml with sitebar.xsl and cache the result SAX
> > events.
> > 2. Transform footer.xml with footer.xsl and cache the result SAX
> > events.
> > 3. Do regular XSLT with the source document, which will get two
> > previous
> > results as named parameters.
> 
> I always totally understud your example but I still don't see the need
> to bother sitemap admins with another construct in the sitemap for
> defining variables. 
> 
> But maybe _I_ am to much fixed on the C2 architecture. I would be
> interested to read other peoples oppinion about this.

I see two "problems" that he is trying to address: speed(hence caching)
and inclusion.
For the speed, I don't think it's an issue, but if you need you can write a 
custom Generator that caches according to you _personal_ needs.
For the inclusion... it's just a matter of making a transformer that
gets parameters in input telling the header and footer... not too hard,
believe me. :-)

nicola_ken

Nicola Ken Barozzi - AISA Industries S.p.A
http://www.aisaindustries.it/
Via Leonardo da Vinci,2 Ticengo (CR) Italy
Research Activity:
Politecnico di Milano - Dipartimento di Meccanica
Piazza Leonardo da Vinci, n.32 - 20133 Milano (Italy)
> > 
> > Zvi wrote:
> > 
> > > Hi Giacomo,
> > >
> > > 1. Do we agree that there is need to implement aggregation on the
> > sitemap
> > > level and not only on the individual XSP page level?
> > > 2. I think that the XML Document Fragment "variable" is the "must
> > have"
> > > concept for C2 sitemap, and it's not increasing FS, as other things
> > people
> > > talking about, on this list. Otherwise I don't see clear way to
> > have
> > > pipelines with multiple sources.
> > > 3. I still don't understand your example, is there stack of results
> > of
> > > intermidiate transforms, that following pipiline components have
> > access to?
> > >
> > > Regards,
> > > Zvi
> > >
> > > Giacomo Pati wrote:
> > >
> > > > --- Zvi <thezvi@ifrance.com> wrote:
> > > > > Hi Giacomo,
> > > > >
> > > > > Giacomo Pati wrote:
> > > > >
> > > > > > Zvi wrote:
> > > > > > >
> > > > > > > skipped...
> > > > > > >
> > > > > > > not so hard, but it's on the individual page level, in
my
> > app I
> > > > > need take the XML
> > > > > > > fragment of sidebar and transform it with XSLT and only
> > then
> > > > > iclude into document.
> > > > > > > Especially highly needed, ability to programmaticaly call
> > XSPs,
> > > > > i.e. include XSP
> > > > > > > inside other XSP without internal HTTP requests. I think
> > better
> > > > > to do that at
> > > > > > > sitemap level, example:
> > > > > > >
> > > > > > >   <match type="uri" pattern="myapp/**">
> > > > > > >         <vaiable name="sitebar">
> > > > > > >           <generate src="myapp/sitebar.xml"/>
> > > > > > >           <transform src="myapp/sitebar.xsl"/>
> > > > > > >         </variable>
> > > > > > >         <vaiable name="footer">
> > > > > > >           <generate src="myapp/footer.xml"/>
> > > > > > >           <transform src="myapp/footer.xsl"/>
> > > > > > >         </variable>
> > > > > > >         <generate src="myapp/page.xml">
> > > > > > >             <param name="sitebar" value="$sitebar"/>
> > > > > > >             <param name="footer" value="$footer"/>
> > > > > > >          </generate>
> > > > > > >         <transform src="myapp/page.xsl"/>
> > > > > > >          <serialize type="html"/>
> > > > > > >   </match>
> > > > > > >
> > > > > > > In short we need aggregation on the sitemap level and not
> > only on
> > > > > the individual XSP
> > > > > > > page level.
> > > > > >
> > > > > > Is it so hard to write a simple transformer that does this???
> > > > > >
> > > > > >   <match type="uri" pattern="myapp/**">
> > > > > >     <generate src="myapp/page.xml">
> > > > > >     <transform type="my-include" src="myapp/sitebar.xml">
> > > > > >       <param name="stylesheet" value="myapp/sitebar.xsl"/>
> > > > > >       <param name="position" value="left"/>
> > > > > >     </transform>
> > > > > >     <transform type="my-include" src="myapp/footer.xml">
> > > > > >       <param name="stylesheet" value="myapp/footer.xsl"/>
> > > > > >       <param name="position" value="bottom"/>
> > > > > >     </transform>
> > > > > >     <transform src="myapp/page.xsl"/>
> > > > > >     <serialize type="html"/>
> > > > > >   </match>
> > > > > >
> > > > > > IMHO its totally easy to write such a "my-include"
> > transformer,
> > > > > don't
> > > > > > you think? And you can easily read it top down.
> > > > >
> > > > > Can you explain how this work?
> > > >
> > > > It works exactly like your example :)
> > > >
> > > > > Is that real C2 sitemap example?
> > > >
> > > > Yes, only the param element is called parameter in C2.
> > > >
> > > > > In my example I need 2 xsp's transformed, before inclusion in
> > another
> > > > > XSP document - and
> > > > > in your example you include them on the transformation stage.
> > > > > And this is not the same thing.
> > > >
> > > > I've never said that the "my-include" transformer doesn't use xsp
> > to
> > > > get the xml from its src= attribute? It totally depends on the
> > > > implementation of that transformer.
> > > >
> > > > > What I don't like in C2 sitemap, that there is many things
> > hidden, to
> > > > > reduce verbosity,
> > > > > but I think it's also reduce redability. What for example
> > happend
> > > > > with results of two
> > > > > intermidiate transforms, how can I understand from this sitemap
> > them
> > > > > going to be included
> > > > > into resulting document?
> > > >
> > > > >From a programmers view point you have to read the description
> > of the
> > > > "my-include" transformer to know what it is doing.
> > > >
> > > > >From a sitemap maintainers view point it depends. If he has to
> > deploy
> > > > that application himself he has to RTFM like an application
> > designer.
> > > > In big installations a application designer will made a
> > deployment
> > > > description for him and then it is not his concern to know how is
> > works
> > > > in detail.
> > > >
> > > > But in general you should have an overview of what a pipeline is
> > and
> > > > how sitemap components like generators/transformers/serializers
> > play
> > > > together to get the basic understanding. So, you're right, it
> > doesn't
> > > > come from just reading the sitemap.
> > > >
> > > > Giacomo
> > > >
> > > > =====
> > > > --
> > > > PWR GmbH, Organisation & Entwicklung      Tel:   +41 (0)1 856
> > 2202
> > > > Giacomo Pati, CTO/CEO                     Fax:   +41 (0)1 856
> > 2201
> > > > Hintereichenstrasse 7                    
> > Mailto:Giacomo.Pati@pwr.ch
> > > > CH-8166 Niederweningen                    Web:  
> > http://www.pwr.ch
> > > >
> > > > __________________________________________________
> > > > Do You Yahoo!?
> > > > Yahoo! Mail - Free email you can access from anywhere!
> > > > http://mail.yahoo.com/
> > 
> 
> 
> =====
> --
> PWR GmbH, Organisation & Entwicklung      Tel:   +41 (0)1 856 2202
> Giacomo Pati, CTO/CEO                     Fax:   +41 (0)1 856 2201
> Hintereichenstrasse 7                     Mailto:Giacomo.Pati@pwr.ch
> CH-8166 Niederweningen                    Web:   http://www.pwr.ch
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Mail - Free email you can access from anywhere!
> http://mail.yahoo.com/
> 


Mime
View raw message