RE: [Q] XScript...

[Vadim Gritsenko <va...@verizon.net>]

Hi Ovidiu,

I'm not sure whether you are following this discussion or not, but I'm
about to refactor XScript in the following direction:

1. Do not store variable scopes in the XScriptManager, but as attribute
of Context, Session, Request, or in the page itself (for page scope).
Thus, will be no (or less) memory leaks (session expires -> all
variables are cleaned up automatically).

2. Add request scope.

3. Move to DOM for variable storage. This will allow adding xpath
functionality to the logicsheet without extra re-parsing.

4. Add XScriptSource, to allow usage of xscript variables in the
sitemap. Something similar to:
<map:generate src="xscript:session:my-doc#chapter[2]"/>
<map:generate src="xscript:first:my-style"/>

5. Think about making single variable storage for xscript and
webapps.session (I would like to get Carsten's comment on this also).

Before I start modifying the code, I would like to hear your opinion on
the decisions I took.


Regards,
Vadim



> From: Per Kreipke [mailto:per@onclave.com]
> 
> > > A couple of questions about XScript 'language':
> > >
> > > - I can't find much (ok, any) documentation about the history of
this
> > > component. What was/is it's purpose? I like it but it would be
nice to
> > > understand its creators' purposes.
> >
> > I am no creator, won't comment.
> >
> >
> > > - the XScriptObjectInlineXML
> >
> > You meant XScriptObjectFromURL
> 
> Doh.
> 
> > > object doesn't use a Resolver so it only seems
> > > to support the http protocol. Is that an oversight or by design?
> >
> > Xscript wasn't maintained well; I already fixed several issues with
it.
> > This is just one more.
> 
> Ok.
> 
> > > - this seems similar to the abilities of some of the sunShine
code.
> >
> > Exactly. It overlaps with webapps.session a bit, although it is
> > different. Session context can be accessed / manipulated in
> > transformation stage only, while xscript works in generation stage,
as
> > logicsheet.
> >
> >
> > > Does SunShine use XScript (not from my searches)?
> >
> > No. They are completely independent (atm).
> >
> >
> > > Is one or the other the
> > > prefered method for manipulating XML snippets?
> >
> > I'm thinking on unifying these two approaches; I'd like to make them
> > share common variable space. Then, it will be two approaches, and
> > difference will be in a stage - generation vs transformation, same
> > difference we see in SQLTransformer vs ESQL logicsheet.
> 
> I agree. That was going to be my next email, just setting the stage
:-)
> 
> Per



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

ComponentSelector could not access the Component for hint: xsp

[Vadim Gritsenko <va...@verizon.net>]

> From: Conny Pemfors [mailto:conny.pemfors@uarda.lu.se]
> 
> Hi Vadim, creator of cocoon,
> 
> why do I get following message:
> 
> 
> org.apache.cocoon.ProcessingException: markup-languages:
ComponentSelector
> could not access the Component for hint: xsp:
> org.apache.avalon.framework.component.ComponentException:
markup-languages:
> ComponentSelector could not access the Component for hint: xsp

What's your configuration? What Cocoon version are you using? Have you
made any changes to it? Have you tried clean/fresh tomcat/cocoon
installation?

There is no enough information to answer your question.


PS Moving to users

Vadim


> It happens every time I try to run a xsp page.
> 
> kind regards
> Conny


---------------------------------------------------------------------
Please check that your question  has not already been answered in the
FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail:     <co...@xml.apache.org>
For additional commands, e-mail:   <co...@xml.apache.org>

Re: [Q] XScript...

[Conny Pemfors <co...@uarda.lu.se>]

Hi Vadim, creator of cocoon,

why do I get following message:


org.apache.cocoon.ProcessingException: markup-languages: ComponentSelector
could not access the Component for hint: xsp:
org.apache.avalon.framework.component.ComponentException: markup-languages:
ComponentSelector could not access the Component for hint: xsp

It happens every time I try to run a xsp page.

kind regards
Conny

----- Original Message -----
From: "Vadim Gritsenko" <va...@verizon.net>
To: "'Ovidiu Predescu'" <ov...@apache.org>
Cc: "'Per Kreipke'" <pe...@onclave.com>; <co...@xml.apache.org>
Sent: Thursday, July 25, 2002 3:51 PM
Subject: RE: [Q] XScript...


> Hi Ovidiu,
>
> I'm not sure whether you are following this discussion or not, but I'm
> about to refactor XScript in the following direction:
>
> 1. Do not store variable scopes in the XScriptManager, but as attribute
> of Context, Session, Request, or in the page itself (for page scope).
> Thus, will be no (or less) memory leaks (session expires -> all
> variables are cleaned up automatically).
>
> 2. Add request scope.
>
> 3. Move to DOM for variable storage. This will allow adding xpath
> functionality to the logicsheet without extra re-parsing.
>
> 4. Add XScriptSource, to allow usage of xscript variables in the
> sitemap. Something similar to:
> <map:generate src="xscript:session:my-doc#chapter[2]"/>
> <map:generate src="xscript:first:my-style"/>
>
> 5. Think about making single variable storage for xscript and
> webapps.session (I would like to get Carsten's comment on this also).
>
> Before I start modifying the code, I would like to hear your opinion on
> the decisions I took.
>
>
> Regards,
> Vadim
>
>
>
> > From: Per Kreipke [mailto:per@onclave.com]
> >
> > > > A couple of questions about XScript 'language':
> > > >
> > > > - I can't find much (ok, any) documentation about the history of
> this
> > > > component. What was/is it's purpose? I like it but it would be
> nice to
> > > > understand its creators' purposes.
> > >
> > > I am no creator, won't comment.
> > >
> > >
> > > > - the XScriptObjectInlineXML
> > >
> > > You meant XScriptObjectFromURL
> >
> > Doh.
> >
> > > > object doesn't use a Resolver so it only seems
> > > > to support the http protocol. Is that an oversight or by design?
> > >
> > > Xscript wasn't maintained well; I already fixed several issues with
> it.
> > > This is just one more.
> >
> > Ok.
> >
> > > > - this seems similar to the abilities of some of the sunShine
> code.
> > >
> > > Exactly. It overlaps with webapps.session a bit, although it is
> > > different. Session context can be accessed / manipulated in
> > > transformation stage only, while xscript works in generation stage,
> as
> > > logicsheet.
> > >
> > >
> > > > Does SunShine use XScript (not from my searches)?
> > >
> > > No. They are completely independent (atm).
> > >
> > >
> > > > Is one or the other the
> > > > prefered method for manipulating XML snippets?
> > >
> > > I'm thinking on unifying these two approaches; I'd like to make them
> > > share common variable space. Then, it will be two approaches, and
> > > difference will be in a stage - generation vs transformation, same
> > > difference we see in SQLTransformer vs ESQL logicsheet.
> >
> > I agree. That was going to be my next email, just setting the stage
> :-)
> >
> > Per
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [Q] XScript...

[Ovidiu Predescu <ov...@apache.org>]

Hi Vadim,

On 7/25/02 6:51 AM, "Vadim Gritsenko" <va...@verizon.net> wrote:

> Hi Ovidiu,
> 
> I'm not sure whether you are following this discussion or not, but I'm
> about to refactor XScript in the following direction:

No, sorry, I was not following it, thanks for the heads up. Where did it
start, I haven't seen it on cocoon-dev?

> 1. Do not store variable scopes in the XScriptManager, but as attribute
> of Context, Session, Request, or in the page itself (for page scope).
> Thus, will be no (or less) memory leaks (session expires -> all
> variables are cleaned up automatically).

Yes, this makes a lot of sense!

> 2. Add request scope.

OK.

> 3. Move to DOM for variable storage. This will allow adding xpath
> functionality to the logicsheet without extra re-parsing.

I agree. The current approach has problems, especially in the context of
namespaces. That's because the XSLT doesn't handle dynamically generated
namespaces. But this is another story.

> 4. Add XScriptSource, to allow usage of xscript variables in the
> sitemap. Something similar to:
> <map:generate src="xscript:session:my-doc#chapter[2]"/>
> <map:generate src="xscript:first:my-style"/>

Wow, this is a neat idea!

> 5. Think about making single variable storage for xscript and
> webapps.session (I would like to get Carsten's comment on this also).

Sorry, I'm not familiar with this, so I cannot comment on it.

> Before I start modifying the code, I would like to hear your opinion on
> the decisions I took.

Sure, just go ahead and do any changes you feel.

My only worry is that Xscript is promoting a page oriented programming
style, which I'm trying to avoid with the flow layer. I worked on Xscript
before the control flow got into my mind, that's why it kind of remained
unmaintained by me.

But I guess we should support both approaches. Given an option people will
ask for it.

Again, thanks for bringing it up! It would be good if you could take up this
portion of the code, and make it fit better with the rest of Cocoon. I don't
feel I have the time to maintain it.

Best regards,
Ovidiu

-- 
Ovidiu Predescu <ov...@apache.org>
http://radio.weblogs.com/0109407/ (Radio Weblog)
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org