You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Peter Donald <do...@apache.org> on 2001/04/22 10:30:06 UTC
Re: cvs commit:
xml-cocoon/src/org/apache/cocoon/components/language/markup/xsp/java
xsp.xsl
At 08:12 22/4/01 -0000, giacomo@apache.org wrote:
>giacomo 01/04/22 01:12:25
> Index: xsp.xsl
> ===================================================================
> RCS file:
/home/cvs/xml-cocoon/src/org/apache/cocoon/components/language/markup/xsp/ja
va/Attic/xsp.xsl,v
> retrieving revision 1.1.2.26
> retrieving revision 1.1.2.27
> diff -u -r1.1.2.26 -r1.1.2.27
> --- xsp.xsl 2001/04/12 16:57:03 1.1.2.26
> +++ xsp.xsl 2001/04/22 08:12:25 1.1.2.27
> @@ -11,7 +11,7 @@
>
> <!--
> * @author <a href="mailto:ricardo@apache.org>Ricardo Rocha</a>
> - * @version CVS $Revision: 1.1.2.26 $ $Date: 2001/04/12 16:57:03 $
> + * @version CVS $Revision: 1.1.2.27 $ $Date: 2001/04/22 08:12:25 $
> -->
>
> <!-- XSP Core logicsheet for the Java language -->
> @@ -43,6 +43,7 @@
> import org.xml.sax.helpers.*;
>
> import org.apache.avalon.*;
> + import org.apache.avalon.component.*;
I would highly recomend that unglobbed versions of imports are used. ie
import org.apache.avalon.component.ComponentManager;
This makes it much easier for new users to identify where a particular
class comes from (otherwise they would have to search through all the
globbed import packages) and it also makes it easy when to refactor using
scripts ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: cvs commit: xml-cocoon/src/org/apache/cocoon/components/language/markup/xsp/java
xsp.xsl
Posted by giacomo <gi...@apache.org>.
On Sun, 22 Apr 2001, Peter Donald wrote:
> At 08:12 22/4/01 -0000, giacomo@apache.org wrote:
> >giacomo 01/04/22 01:12:25
> > Index: xsp.xsl
> > ===================================================================
> > RCS file:
> /home/cvs/xml-cocoon/src/org/apache/cocoon/components/language/markup/xsp/ja
> va/Attic/xsp.xsl,v
> > retrieving revision 1.1.2.26
> > retrieving revision 1.1.2.27
> > diff -u -r1.1.2.26 -r1.1.2.27
> > --- xsp.xsl 2001/04/12 16:57:03 1.1.2.26
> > +++ xsp.xsl 2001/04/22 08:12:25 1.1.2.27
> > @@ -11,7 +11,7 @@
> >
> > <!--
> > * @author <a href="mailto:ricardo@apache.org>Ricardo Rocha</a>
> > - * @version CVS $Revision: 1.1.2.26 $ $Date: 2001/04/12 16:57:03 $
> > + * @version CVS $Revision: 1.1.2.27 $ $Date: 2001/04/22 08:12:25 $
> > -->
> >
> > <!-- XSP Core logicsheet for the Java language -->
> > @@ -43,6 +43,7 @@
> > import org.xml.sax.helpers.*;
> >
> > import org.apache.avalon.*;
> > + import org.apache.avalon.component.*;
>
> I would highly recomend that unglobbed versions of imports are used. ie
>
> import org.apache.avalon.component.ComponentManager;
>
> This makes it much easier for new users to identify where a particular
> class comes from (otherwise they would have to search through all the
> globbed import packages) and it also makes it easy when to refactor using
> scripts ;)
Ok, I've started to explicitly import classes based on the samples we
have. I'm sure people will come with other classes made available per
default.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: cvs commit: xml-cocoon/src/org/apache/cocoon/components/language/markup/xsp/java
xsp.xsl
Posted by Donald Ball <ba...@webslingerZ.com>.
On Sun, 22 Apr 2001, giacomo wrote:
> One reason doing so is that a XSP page can access "common" classes
> without having to define them via xsp:structure element ut I can agree
> with you.
-1, we should explicitly enumerate which class names are imported for xsp
pages.
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: cvs commit: xml-cocoon/src/org/apache/cocoon/components/language/markup/xsp/java
xsp.xsl
Posted by giacomo <gi...@apache.org>.
On Sun, 22 Apr 2001, Peter Donald wrote:
> At 08:12 22/4/01 -0000, giacomo@apache.org wrote:
> >giacomo 01/04/22 01:12:25
> > Index: xsp.xsl
> > ===================================================================
> > RCS file:
> /home/cvs/xml-cocoon/src/org/apache/cocoon/components/language/markup/xsp/ja
> va/Attic/xsp.xsl,v
> > retrieving revision 1.1.2.26
> > retrieving revision 1.1.2.27
> > diff -u -r1.1.2.26 -r1.1.2.27
> > --- xsp.xsl 2001/04/12 16:57:03 1.1.2.26
> > +++ xsp.xsl 2001/04/22 08:12:25 1.1.2.27
> > @@ -11,7 +11,7 @@
> >
> > <!--
> > * @author <a href="mailto:ricardo@apache.org>Ricardo Rocha</a>
> > - * @version CVS $Revision: 1.1.2.26 $ $Date: 2001/04/12 16:57:03 $
> > + * @version CVS $Revision: 1.1.2.27 $ $Date: 2001/04/22 08:12:25 $
> > -->
> >
> > <!-- XSP Core logicsheet for the Java language -->
> > @@ -43,6 +43,7 @@
> > import org.xml.sax.helpers.*;
> >
> > import org.apache.avalon.*;
> > + import org.apache.avalon.component.*;
>
> I would highly recomend that unglobbed versions of imports are used. ie
>
> import org.apache.avalon.component.ComponentManager;
>
> This makes it much easier for new users to identify where a particular
> class comes from (otherwise they would have to search through all the
> globbed import packages) and it also makes it easy when to refactor using
> scripts ;)
One reason doing so is that a XSP page can access "common" classes
without having to define them via xsp:structure element ut I can agree
with you.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org