You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Donald Ball <ba...@webslingerZ.com> on 2000/06/17 18:32:36 UTC
sitemap draft still needs work in the matcher/chooser area
Welp, I had a few minutes last night to poke around cocoon2. Daunted by
the size of the sitemap coding task ahead of us, I nonetheless decided to
start writing some code. I decided to tackle the matcher components, since
they're well-defined and straightforward, and Stefano and I had a huge
disagreement about them a couple of weeks ago. What better way to enforce
my world view than to be the implementor? No one argues with working code
;)
Anyway, I just checked in the smidgen of code I wrote (Stefano, bless his
heart, _just_ changed the name from matcher to chooser in the sitemap
draft). However, it doesn't do much since I'm not sure how to address a
couple of issues yet:
1. where should do site or directory-specific configuration of components?
take the AuthenticationMatcher, for instance. An obvious implementation
would be the FileAuthenticationMatcher. How do I know where to look for
the file? The only place in the current sitemap draft where I'm allowed to
configure matchers in in the declaration of components block - but suppose
I want to have different files for different directories?
2. exactly how is the choose/when stuff supposed to work? i see that the
type attribute of the choose tag indicates which chooser is assigned to
test the condition, but what happens then? should the chooser API look
something like this:
boolean choose(Request request, String test);
where test is the value of the test attribute of the when element? what
form are the test expressions allowed to take? they look an awful lot like
XPath expressions to me... :)
- donald
Re: sitemap draft still needs work in the matcher/chooser area
Posted by Ross Burton <ro...@mail.com>.
> 2. exactly how is the choose/when stuff supposed to work? i see that the
> type attribute of the choose tag indicates which chooser is assigned to
> test the condition, but what happens then? should the chooser API look
> something like this:
>
> boolean choose(Request request, String test);
>
> where test is the value of the test attribute of the when element? what
> form are the test expressions allowed to take? they look an awful lot like
> XPath expressions to me... :)
If I recall correctly (unless it changed overnight) if the Cocoon found this
in the sitemap:
<choose type="browser">
<when test="accepts('image/svg')">
...
</when>
<default>
...
</default>
</choose>
It calls the method "accepts" using reflection with the string argument
"image/svg" on the Chooser called "browser" which was loaded as a Component.
However, the lack of a interface actually defining any methods could be seen
as a problem, so Choose could define :
public boolean choose(String test, String argument);
And the sitemap would work by calling:
Choose b = manager.getComponent("browser");
b.choose("accepts", "image/svg");
Which gives the Chooser inteface something concrete to work on - beginners
to Cocoon matchers, sorry Choosers, may miss the point that dynamic method
calls are being made.
Ross Burton
RE: sitemap draft still needs work in the matcher/chooser area
Posted by David Duddleston <da...@i2a.com>.
> -----Original Message-----
> From: N. Sean Timm [mailto:stimm@mailgo.com]
> Sent: Sunday, June 18, 2000 11:51 AM
> To: cocoon-dev@xml.apache.org
> Subject: Re: sitemap draft still needs work in the matcher/chooser area
>
>
> I'm fairly neutral right now on whether or not Cocoon itself does any sort
> of authentication or authorization (I haven't spent much time
> thinking about
> it), but I do know that my company has custom authentication methods that
> have to occur, and these will be implemented as choosers. I was
> just going
> to bring up a point about needing a global process path, when I realized
> that we have that with the current sitemap proposal. Now that
> it's not URI
> dependant, I can have my first match be on an authorization chooser, and
> then pass them to a login process or on to their requested
> process depending
> on the return result...cool!
Yeah, cool is right. I think in this aspect (custom authorization chooser),
the ability to do authorization at the sitemap level could be considered
covered. Now is it reasonable to provide a basic authorization chooser for
the distribution?
-david
Re: sitemap draft still needs work in the matcher/chooser area
Posted by "N. Sean Timm" <st...@mailgo.com>.
I'm fairly neutral right now on whether or not Cocoon itself does any sort
of authentication or authorization (I haven't spent much time thinking about
it), but I do know that my company has custom authentication methods that
have to occur, and these will be implemented as choosers. I was just going
to bring up a point about needing a global process path, when I realized
that we have that with the current sitemap proposal. Now that it's not URI
dependant, I can have my first match be on an authorization chooser, and
then pass them to a login process or on to their requested process depending
on the return result...cool!
- Sean T.
----- Original Message -----
From: "brian moseley" <ix...@maz.org>
To: <co...@xml.apache.org>
Sent: Sunday, June 18, 2000 12:32 PM
Subject: Re: sitemap draft still needs work in the matcher/chooser area
> On Sun, 18 Jun 2000, Giacomo Pati wrote:
>
> > Authentication is the process of identifying who is the
> > requestor. Authorisation is the process of
> > allowing/denying access to the resource requested.
>
> yes i know that already. your definitions don't prove why
> the mechanical act of authorization should be cocoon's
> responsibility.
>
Re: sitemap draft still needs work in the matcher/chooser area
Posted by brian moseley <ix...@maz.org>.
On Sun, 18 Jun 2000, Giacomo Pati wrote:
> Authentication is the process of identifying who is the
> requestor. Authorisation is the process of
> allowing/denying access to the resource requested.
yes i know that already. your definitions don't prove why
the mechanical act of authorization should be cocoon's
responsibility.
Re: sitemap draft still needs work in the matcher/chooser area
Posted by Giacomo Pati <Gi...@pwr.ch>.
On Sat, Jun 17, 2000 at 07:03:34PM -0700, brian moseley wrote:
> On Sat, 17 Jun 2000, David Duddleston wrote:
>
> > The issue of authentication has been discussed
> > previously and the verdict was to leave authentication
> > to the Servlet container or Web server. Authorization is
> > another issue.
>
> it is? why?
Authentication is the process of identifying who is the requestor.
Authorisation is the process of allowing/denying access to the resource requested.
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
RE: sitemap draft still needs work in the matcher/chooser area
Posted by Donald Ball <ba...@webslingerZ.com>.
On Sat, 17 Jun 2000, David Duddleston wrote:
> The issue of authentication has been discussed previously and the verdict
> was to leave authentication to the Servlet container or Web server.
> Authorization is another issue.
a. i don't remember this being decided
b. i don't particularly care one way one or another - my question is
_technical_ - how do i configure a chooser/matcher differently in several
places in the same sitemap? - not religious.
c. if i did care, i would argue thusly - generally users and groups are
defined in the same place (file, database, whatever). if we do
authentication (determing that a user is who they say they are) in one
place (web server) and authorization (figure out what groups a user belong
to) in another place (cocoon), that means you have to replicate the
information for accessing the data source (file url; database url, driver,
username, password, table names, etc.) in two places.
anyway, hell, if all i end up using the web server for is talking http, os
interaction, and logging, i'm _fine_ with that.
- donald
RE: sitemap draft still needs work in the matcher/chooser area
Posted by David Duddleston <da...@i2a.com>.
> -----Original Message-----
> From: brian moseley [mailto:ix@maz.org]
> Sent: Saturday, June 17, 2000 7:04 PM
> To: cocoon-dev@xml.apache.org
> Subject: RE: sitemap draft still needs work in the matcher/chooser area
>
>
> On Sat, 17 Jun 2000, David Duddleston wrote:
>
> > The issue of authentication has been discussed
> > previously and the verdict was to leave authentication
> > to the Servlet container or Web server. Authorization is
> > another issue.
>
> it is? why?
Only in that authentication of some sort will probably be built into sitemap
somehow. "Another issue" poor choice of words I guess. I should have said...
to be determined.
-david
RE: sitemap draft still needs work in the matcher/chooser area
Posted by brian moseley <ix...@maz.org>.
On Sat, 17 Jun 2000, David Duddleston wrote:
> The issue of authentication has been discussed
> previously and the verdict was to leave authentication
> to the Servlet container or Web server. Authorization is
> another issue.
it is? why?
RE: sitemap draft still needs work in the matcher/chooser area
Posted by David Duddleston <da...@i2a.com>.
The issue of authentication has been discussed previously and the verdict
was to leave authentication to the Servlet container or Web server.
Authorization is another issue.
-david
> On Sat, 17 Jun 2000, Donald Ball wrote:
>
> > b. i think there's a place for user authentication inside cocoon,
>
> I have to say that putting authentication into cocoon seems like a REALLY
> bad idea to me (I may be being shortsighted, I'm sure you'll let me know
> ;). Whether it's FileMatcher or IPAddressMatcher or whatever, we'd be
> looking at re-implementing vast chunks of code that is already done and
> dusted in many webservers. Is authentication _really_ Cocoon's job?
>
>
> Andrew.
>
> ------------------------------------------------------------------
> -----------
> Web Consultant | Email: a.savory at uea.ac.uk
> Library and Learning Resources | URL: http://www.uea.ac.uk/
> University of East Anglia | All views are my own -
> Norwich, NR4 7TJ, UK | who else
> would want them?
> ------------------------------------------------------------------
> -----------
>
Re: sitemap draft still needs work in the matcher/chooser area
Posted by brian moseley <ix...@maz.org>.
On Sat, 17 Jun 2000, Donald Ball wrote:
> Is mapping URLspace to filespace really cocoon's job?
> That's traditionally the job of a web server as well.
only when it's really just serving files. cocoon doesn't
limit itself thus.
> Since we're carving out URLspace in the cocoon sitemap,
> doesn't it make sense to at least offer the option to
> have access to the various URLs limited in the sitemap?
> Read over the current sitemap working draft and see if
> you're still in disagreement.
i go back and forth on this issue, but currently i think
authentication and authorization should be managed by the
environment, not by the content production engine. the
intersection of the two should only ever be in
configuration.
Re: sitemap draft still needs work in the matcher/chooser area
Posted by Donald Ball <ba...@webslingerZ.com>.
On Sun, 18 Jun 2000, Andrew Savory wrote:
> On Sat, 17 Jun 2000, Donald Ball wrote:
>
> > b. i think there's a place for user authentication inside cocoon,
>
> I have to say that putting authentication into cocoon seems like a REALLY
> bad idea to me (I may be being shortsighted, I'm sure you'll let me know
> ;). Whether it's FileMatcher or IPAddressMatcher or whatever, we'd be
> looking at re-implementing vast chunks of code that is already done and
> dusted in many webservers. Is authentication _really_ Cocoon's job?
Is mapping URLspace to filespace really cocoon's job? That's traditionally
the job of a web server as well. Since we're carving out URLspace in the
cocoon sitemap, doesn't it make sense to at least offer the option to have
access to the various URLs limited in the sitemap? Read over the current
sitemap working draft and see if you're still in disagreement.
- donald
Re: sitemap draft still needs work in the matcher/chooser area
Posted by Andrew Savory <A....@uea.ac.uk>.
On Sat, 17 Jun 2000, Donald Ball wrote:
> b. i think there's a place for user authentication inside cocoon,
I have to say that putting authentication into cocoon seems like a REALLY
bad idea to me (I may be being shortsighted, I'm sure you'll let me know
;). Whether it's FileMatcher or IPAddressMatcher or whatever, we'd be
looking at re-implementing vast chunks of code that is already done and
dusted in many webservers. Is authentication _really_ Cocoon's job?
Andrew.
-----------------------------------------------------------------------------
Web Consultant | Email: a.savory at uea.ac.uk
Library and Learning Resources | URL: http://www.uea.ac.uk/
University of East Anglia | All views are my own -
Norwich, NR4 7TJ, UK | who else would want them?
-----------------------------------------------------------------------------
Re: sitemap draft still needs work in the matcher/chooser area
Posted by Donald Ball <ba...@webslingerZ.com>.
On Sun, 18 Jun 2000, Giacomo Pati wrote:
> > 1. where should do site or directory-specific configuration of components?
> > take the AuthenticationMatcher, for instance. An obvious implementation
> > would be the FileAuthenticationMatcher. How do I know where to look for
> > the file? The only place in the current sitemap draft where I'm allowed to
> > configure matchers in in the declaration of components block - but suppose
> > I want to have different files for different directories?
>
> I thought we agreed _not_ to authenticate ourselfs! We leave it to the
> servlet engine/web server. So please don't write a
> FileAuthenticationMatcher, write a FileAuthorisationMatcher instead!
well...
a. it's just an example. substitute IPAddressMatcher instead - the problem
remains - how do I configure the matcher to work differently in different
places?
b. i think there's a place for user authentication inside cocoon,
especially if we're going to be carving out a huge chunk of URLspace (not
just .xml files) and serving it instead of using apache's URL-to-file
mapping. but if you don't want to use it, don't.
c. what do you see as the difference between a FileAuthenticationMatcher
and FileAuthorisationMatcher?
- donald
Re: sitemap draft still needs work in the matcher/chooser area
Posted by Giacomo Pati <Gi...@pwr.ch>.
Donald Ball wrote:
>
> Welp, I had a few minutes last night to poke around cocoon2. Daunted by
> the size of the sitemap coding task ahead of us, I nonetheless decided to
> start writing some code. I decided to tackle the matcher components, since
> they're well-defined and straightforward, and Stefano and I had a huge
> disagreement about them a couple of weeks ago. What better way to enforce
> my world view than to be the implementor? No one argues with working code
> ;)
Yes, you're totally right. Let's do it.
As I've played lately with trax I will change all the serializers to use
the serializer.* package from trax. But I should start another thread
for this.
>
> Anyway, I just checked in the smidgen of code I wrote (Stefano, bless his
> heart, _just_ changed the name from matcher to chooser in the sitemap
> draft). However, it doesn't do much since I'm not sure how to address a
> couple of issues yet:
>
> 1. where should do site or directory-specific configuration of components?
> take the AuthenticationMatcher, for instance. An obvious implementation
> would be the FileAuthenticationMatcher. How do I know where to look for
> the file? The only place in the current sitemap draft where I'm allowed to
> configure matchers in in the declaration of components block - but suppose
> I want to have different files for different directories?
I thought we agreed _not_ to authenticate ourselfs! We leave it to the
servlet engine/web server. So please don't write a
FileAuthenticationMatcher, write a FileAuthorisationMatcher instead!
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
RE: sitemap draft still needs work in the matcher/chooser area
Posted by David Duddleston <da...@i2a.com>.
> note this poses some parsing problems that we might easily solve with
>
> <when method="..." test="...">
>
> where the "default" method is IMPLIED if not expressed.
I like this approach best.
-david
Re: sitemap draft still needs work in the matcher/chooser area
Posted by Stefano Mazzocchi <st...@apache.org>.
Donald Ball wrote:
>
> On Sun, 18 Jun 2000, Stefano Mazzocchi wrote:
>
> > Donald Ball wrote:
> > >
> > > Welp, I had a few minutes last night to poke around cocoon2. Daunted by
> > > the size of the sitemap coding task ahead of us
> >
> > It's not that bad after all.
>
> yeah, well, the rate of progression of the code belies that myth.
The rate of progression of the code depends on two months lost because
of process faults and many other problems it's not fair to list here
that go well beyond code length of complexity.
Besides, I remind you I haven't touched the C2 codebase yet.
> > > However, it doesn't do much since I'm not sure how to address a
> > > couple of issues yet:
> > >
> > > 1. where should do site or directory-specific configuration of components?
> > > take the AuthenticationMatcher, for instance. An obvious implementation
> > > would be the FileAuthenticationMatcher. How do I know where to look for
> > > the file? The only place in the current sitemap draft where I'm allowed to
> > > configure matchers in in the declaration of components block - but suppose
> > > I want to have different files for different directories?
> >
> > this is where sitemap mounting should help, sort of .htaccess
> > equivalent.
> >
> > But I'm open to suggestions, of course.
>
> hmm. not sure if i made myself clear. okay, suppose we have a chooser
> which relies on a resource from the filesystem - call it the FoobarChooser
> to avoid any more fights about doing user auth. i want to have the chooser
> use two different files in different parts of the map. we don't have a
> syntax for that right now. how about this:
>
> <choosers>
> <chooser type="foobar" src:class="org.apache.cocoon.tester.FoobarChooser">
> <param name="src" value="/usr/local/etc/foobar.xml"/>
> </chooser>
> </choosers>
>
> <pipeline>
> <choose type="foobar">
> <param name="src" value="/home/balld/etc/foobar.xml"/>
> <when test="foobar('bat')">
> <generator/>
> <serializer/>
> </when>
> <otherwise>
> ...
> </otherwise>
> </choose>
> </pipeline>
>
> that covers the multiple configuration problem. now suppose i wanted to
> use a relative path in the src parameter - what would it be relative to?
> the sitemap in which the param element appears? could we use xml:base?
Good point.... sheesh, the loader namespace doesn't work "inside
attributes"... should we get back to URL encoding instead?
> > > 2. exactly how is the choose/when stuff supposed to work? i see that the
> > > type attribute of the choose tag indicates which chooser is assigned to
> > > test the condition, but what happens then? should the chooser API look
> > > something like this:
> > >
> > > boolean choose(Request request, String test);
> >
> > no
> >
> > Map xxx(CocoonRequest request, String test);
> >
> > where
> >
> > Map is a collection of key-value pairs
> > xxx is the name of the test ("default" is the default one)
> > Request the CocoonRequest that comes to Cocoon
> > test the "test" attribute of the "when" element
> >
> > for example:
> >
> > <choose type="uri">
> > <when test="/docs/*">
> > </when>
> > <when test="regexp('...')"/>
> > </when>
> > </choose>
> >
> > then you have
> >
> > public class URIChooser implements Chooser {
> > Map default(CocoonRequest request, String test) {
> > // perform wildcard matching filling the map with matched tokens
> > if (matched)
> > return tokenMap;
> > else
> > return null;
> > }
> >
> > Map regexp(CocoonRequest request, String test) {
> > // perform regexp matching filling the map with matched tokens
> > if (matched)
> > return tokenMap;
> > else
> > return null;
> > }
> > }
>
> I'm afraid I don't get the Map thing. How would it work for a simple
> boolean test like FoobarChooser does?
final static public Map true = new MapImpl();
final static public Map false = null;
if (matched)
return true;
else
return false;
Admittedly not super-elegant, but how do we do tests and pass tokens to
the pipeline?
Should we peparate "choosers" and "param tokenizers"?
> > > where test is the value of the test attribute of the when element? what
> > > form are the test expressions allowed to take?
> >
> > test="..." for the default method
> >
> > test="xxx('...')" for the xxx method
> >
> > note this poses some parsing problems that we might easily solve with
> >
> > <when method="..." test="...">
> >
> > where the "default" method is IMPLIED if not expressed.
>
> er, well, that might make calling methods with multiple parameters a bit
> trickier...
true
> > > they look an awful lot like XPath expressions to me... :)
> >
> > What do you suggest?
>
> you _know_ what i suggest - that we actually use XPath for real here.
hmmmm
> Construct a virtual DOM (with callbacks, not actually filled in) with all
> of the request-time information, provide handy global variables for
> commonly used stuff (browser, etc.) and let sitemap authors write XPath
> expressions in their sitemaps:
>
> <choose>
> <when test="$browser='netscape' and $language='en'">
> ...
> </when>
> </choose>
>
> i stopped arguing about it, but still, the more i think about it, the more
> i think this approach makes more sense than what i currently see in the
> sitemap working draft.
Ok, let us suppose we do this. How do we extend this virtual request
schema, if needed?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: merlot editor
Posted by Mark Washeim <es...@canuck.com>.
on 21/6/00 2:28 am, David Duddleston at david@i2a.com wrote:
>
> Are you talking about XML Notepad. I tried a bunch of different editors for
> data entry and I liked it the best because of the field tabing feature.
>
> -david
>
Yeah, I was referring to wee little XML notepad. I liked it for the very
same reason . . . we're implementing field tabbing, too . . .
>
--
Mark (Poetaster) Washeim
'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.
Quem colorem habet sapientia?'
Evan S. Connell
RE: merlot editor
Posted by David Duddleston <da...@i2a.com>.
Are you talking about XML Notepad. I tried a bunch of different editors for
data entry and I liked it the best because of the field tabing feature.
-david
> -----Original Message-----
> From: Mark Washeim [mailto:esalon@canuck.com]
> Sent: Tuesday, June 20, 2000 11:00 AM
> To: cocoon-dev@xml.apache.org
> Subject: Re: merlot editor
>
>
> on 20/6/00 8:30 am, Niclas Hedhman at niclas@localbar.com wrote:
>
> > Stefano Mazzocchi wrote:
> >
> >> Mark Washeim wrote:
> >>>
> >>> http://www.merlotxml.org
> >>
> >> (even if Merlot's idea of XML editing is totally opposite to mine...
> >> well, I understand I'm a weirdo so I don't really count...)
> >
> > I agree that the tree-based editor is not very easy, nor
> intuitive, to work
> > with. And a lot of clicking is normally the result. I am sure
> the standard
> > word
> > processor view of documents are a better way to go, and the
> tree view is some
> > "Page Source" option. Anyway, a bit off-topic here to discuss
> the ultimate XML
> > editor.
> >
> > Niclas
> >
>
> Though i hate to say it, microsoft issued a small, non-validating
> xml editor
> about 2 years ago which was just great... it did use a tree view but with
> the ability to auto expand nodes as you tabbed through them such that you
> could tab open nodes and then tab to the content node to edit
> very easily .
> . . I'll try to whip up one like it in java once I've finished with the
> eurofootball site . . .
>
> our editor also uses a tree, but depends on schema. in the main, depending
> on the document, what you see first are the fields or selection
> affordances
> for the top-most complex-type. What that means is, that you don't
> depend on
> the tree, but rather a panel at a time, the more complex types. . .
>
> so, for a complex-type composed of, for instance:
> simple-type - addressOne
> simple-type - addressTwo
> simple-type - city
> simple-type - province/county
> simple-type - postalcode
>
> you would see all those simple types (which don't contain any
> further nodes,
> anyway) at once when clicking on the complex type's node (let's call it
> address) . . .
>
> I'm trying, I'm trying to get you guys a copy, were just really swamped!
>
>
>
>
>
>
>
> --
> Mark (Poetaster) Washeim
>
> 'On the linen wrappings of certain mummified remains
> found near the Etrurian coast are invaluable writings
> that await translation.
>
> Quem colorem habet sapientia?'
>
> Evan S. Connell
>
>
>
>
Re: merlot editor
Posted by Mark Washeim <es...@canuck.com>.
on 20/6/00 8:30 am, Niclas Hedhman at niclas@localbar.com wrote:
> Stefano Mazzocchi wrote:
>
>> Mark Washeim wrote:
>>>
>>> http://www.merlotxml.org
>>
>> (even if Merlot's idea of XML editing is totally opposite to mine...
>> well, I understand I'm a weirdo so I don't really count...)
>
> I agree that the tree-based editor is not very easy, nor intuitive, to work
> with. And a lot of clicking is normally the result. I am sure the standard
> word
> processor view of documents are a better way to go, and the tree view is some
> "Page Source" option. Anyway, a bit off-topic here to discuss the ultimate XML
> editor.
>
> Niclas
>
Though i hate to say it, microsoft issued a small, non-validating xml editor
about 2 years ago which was just great... it did use a tree view but with
the ability to auto expand nodes as you tabbed through them such that you
could tab open nodes and then tab to the content node to edit very easily .
. . I'll try to whip up one like it in java once I've finished with the
eurofootball site . . .
our editor also uses a tree, but depends on schema. in the main, depending
on the document, what you see first are the fields or selection affordances
for the top-most complex-type. What that means is, that you don't depend on
the tree, but rather a panel at a time, the more complex types. . .
so, for a complex-type composed of, for instance:
simple-type - addressOne
simple-type - addressTwo
simple-type - city
simple-type - province/county
simple-type - postalcode
you would see all those simple types (which don't contain any further nodes,
anyway) at once when clicking on the complex type's node (let's call it
address) . . .
I'm trying, I'm trying to get you guys a copy, were just really swamped!
--
Mark (Poetaster) Washeim
'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.
Quem colorem habet sapientia?'
Evan S. Connell
Re: merlot editor
Posted by Niclas Hedhman <ni...@localbar.com>.
Stefano Mazzocchi wrote:
> Mark Washeim wrote:
> >
> > http://www.merlotxml.org
>
> (even if Merlot's idea of XML editing is totally opposite to mine...
> well, I understand I'm a weirdo so I don't really count...)
I agree that the tree-based editor is not very easy, nor intuitive, to work
with. And a lot of clicking is normally the result. I am sure the standard word
processor view of documents are a better way to go, and the tree view is some
"Page Source" option. Anyway, a bit off-topic here to discuss the ultimate XML
editor.
Niclas
Re: merlot editor
Posted by Mark Washeim <es...@canuck.com>.
on 19/6/00 8:19 pm, Stefano Mazzocchi at stefano@apache.org wrote:
> Mark Washeim wrote:
>>
>> http://www.merlotxml.org
>>
>> not sure how many of you already knew of the project . . . we're trying to
>> keep in touch with them to try to converge our editor efforts . . .
>
> That would be great.
>
> (even if Merlot's idea of XML editing is totally opposite to mine...
> well, I understand I'm a weirdo so I don't really count...)
I've been puzzling over the question of how what are, ostensibly, plain text
documents should be edited.
I use vi ;)
I think it's simple and depends, primarily on the workflow context...
namely, in cases where the documents in question are 'formal', a forms
approach (not HTML forms, but, field wise, nevertheless) is called for. It's
also the nature of that kind of document management.
Some would immediately object and say, well, then, why not just an RDBMS
with a forms (Oracle, for instance) interface... My answer to which is,
ascii rules. Seriously, even if you incur the overhead of transforming sql
results into xml (which using Donald's sql tag-lib makes a snap!) is well
worth it in terms of the ease with which the structure can be transformed .
. . namely XSL rooools, too.
For documents which are not amenable to a forms treatment, my opinion isn't
firm yet . . . I'd like a free text editor which transforms all my
formatting into mark-up a al docbook . . . but, that's a bit of a parsing
nightmare, thereafter . . . sigh, not sure yet . . .
--
Mark (Poetaster) Washeim
'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.
Quem colorem habet sapientia?'
Evan S. Connell
Re: merlot editor
Posted by Stefano Mazzocchi <st...@apache.org>.
Mark Washeim wrote:
>
> http://www.merlotxml.org
>
> not sure how many of you already knew of the project . . . we're trying to
> keep in touch with them to try to converge our editor efforts . . .
That would be great.
(even if Merlot's idea of XML editing is totally opposite to mine...
well, I understand I'm a weirdo so I don't really count...)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
merlot editor
Posted by Mark Washeim <es...@canuck.com>.
http://www.merlotxml.org
not sure how many of you already knew of the project . . . we're trying to
keep in touch with them to try to converge our editor efforts . . .
--
Mark (Poetaster) Washeim
large medium
'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.
Quem colorem habet sapientia?'
Evan S. Connell
Re: sitemap draft still needs work in the matcher/chooser area
Posted by Donald Ball <ba...@webslingerZ.com>.
On Sun, 18 Jun 2000, Stefano Mazzocchi wrote:
> Donald Ball wrote:
> >
> > Welp, I had a few minutes last night to poke around cocoon2. Daunted by
> > the size of the sitemap coding task ahead of us
>
> It's not that bad after all.
yeah, well, the rate of progression of the code belies that myth.
> > However, it doesn't do much since I'm not sure how to address a
> > couple of issues yet:
> >
> > 1. where should do site or directory-specific configuration of components?
> > take the AuthenticationMatcher, for instance. An obvious implementation
> > would be the FileAuthenticationMatcher. How do I know where to look for
> > the file? The only place in the current sitemap draft where I'm allowed to
> > configure matchers in in the declaration of components block - but suppose
> > I want to have different files for different directories?
>
> this is where sitemap mounting should help, sort of .htaccess
> equivalent.
>
> But I'm open to suggestions, of course.
hmm. not sure if i made myself clear. okay, suppose we have a chooser
which relies on a resource from the filesystem - call it the FoobarChooser
to avoid any more fights about doing user auth. i want to have the chooser
use two different files in different parts of the map. we don't have a
syntax for that right now. how about this:
<choosers>
<chooser type="foobar" src:class="org.apache.cocoon.tester.FoobarChooser">
<param name="src" value="/usr/local/etc/foobar.xml"/>
</chooser>
</choosers>
<pipeline>
<choose type="foobar">
<param name="src" value="/home/balld/etc/foobar.xml"/>
<when test="foobar('bat')">
<generator/>
<serializer/>
</when>
<otherwise>
...
</otherwise>
</choose>
</pipeline>
that covers the multiple configuration problem. now suppose i wanted to
use a relative path in the src parameter - what would it be relative to?
the sitemap in which the param element appears? could we use xml:base?
> > 2. exactly how is the choose/when stuff supposed to work? i see that the
> > type attribute of the choose tag indicates which chooser is assigned to
> > test the condition, but what happens then? should the chooser API look
> > something like this:
> >
> > boolean choose(Request request, String test);
>
> no
>
> Map xxx(CocoonRequest request, String test);
>
> where
>
> Map is a collection of key-value pairs
> xxx is the name of the test ("default" is the default one)
> Request the CocoonRequest that comes to Cocoon
> test the "test" attribute of the "when" element
>
> for example:
>
> <choose type="uri">
> <when test="/docs/*">
> </when>
> <when test="regexp('...')"/>
> </when>
> </choose>
>
> then you have
>
> public class URIChooser implements Chooser {
> Map default(CocoonRequest request, String test) {
> // perform wildcard matching filling the map with matched tokens
> if (matched)
> return tokenMap;
> else
> return null;
> }
>
> Map regexp(CocoonRequest request, String test) {
> // perform regexp matching filling the map with matched tokens
> if (matched)
> return tokenMap;
> else
> return null;
> }
> }
I'm afraid I don't get the Map thing. How would it work for a simple
boolean test like FoobarChooser does?
> > where test is the value of the test attribute of the when element? what
> > form are the test expressions allowed to take?
>
> test="..." for the default method
>
> test="xxx('...')" for the xxx method
>
> note this poses some parsing problems that we might easily solve with
>
> <when method="..." test="...">
>
> where the "default" method is IMPLIED if not expressed.
er, well, that might make calling methods with multiple parameters a bit
trickier...
> > they look an awful lot like XPath expressions to me... :)
>
> What do you suggest?
you _know_ what i suggest - that we actually use XPath for real here.
Construct a virtual DOM (with callbacks, not actually filled in) with all
of the request-time information, provide handy global variables for
commonly used stuff (browser, etc.) and let sitemap authors write XPath
expressions in their sitemaps:
<choose>
<when test="$browser='netscape' and $language='en'">
...
</when>
</choose>
i stopped arguing about it, but still, the more i think about it, the more
i think this approach makes more sense than what i currently see in the
sitemap working draft.
- donald
Re: sitemap draft still needs work in the matcher/chooser area
Posted by Stefano Mazzocchi <st...@apache.org>.
Donald Ball wrote:
>
> Welp, I had a few minutes last night to poke around cocoon2. Daunted by
> the size of the sitemap coding task ahead of us
It's not that bad after all.
> I nonetheless decided to start writing some code.
> I decided to tackle the matcher components, since
> they're well-defined and straightforward, and Stefano and I had a huge
> disagreement about them a couple of weeks ago. What better way to enforce
> my world view than to be the implementor? No one argues with working code
> ;)
what a kid :)
> Anyway, I just checked in the smidgen of code I wrote (Stefano, bless his
> heart, _just_ changed the name from matcher to chooser in the sitemap
> draft).
eh, eh, eh :)
Anyway, I do agree that "chooser" is kind of a silly, I'll let you guys
decide the name for this.
> However, it doesn't do much since I'm not sure how to address a
> couple of issues yet:
>
> 1. where should do site or directory-specific configuration of components?
> take the AuthenticationMatcher, for instance. An obvious implementation
> would be the FileAuthenticationMatcher. How do I know where to look for
> the file? The only place in the current sitemap draft where I'm allowed to
> configure matchers in in the declaration of components block - but suppose
> I want to have different files for different directories?
this is where sitemap mounting should help, sort of .htaccess
equivalent.
But I'm open to suggestions, of course.
> 2. exactly how is the choose/when stuff supposed to work? i see that the
> type attribute of the choose tag indicates which chooser is assigned to
> test the condition, but what happens then? should the chooser API look
> something like this:
>
> boolean choose(Request request, String test);
no
Map xxx(CocoonRequest request, String test);
where
Map is a collection of key-value pairs
xxx is the name of the test ("default" is the default one)
Request the CocoonRequest that comes to Cocoon
test the "test" attribute of the "when" element
for example:
<choose type="uri">
<when test="/docs/*">
</when>
<when test="regexp('...')"/>
</when>
</choose>
then you have
public class URIChooser implements Chooser {
Map default(CocoonRequest request, String test) {
// perform wildcard matching filling the map with matched tokens
if (matched)
return tokenMap;
else
return null;
}
Map regexp(CocoonRequest request, String test) {
// perform regexp matching filling the map with matched tokens
if (matched)
return tokenMap;
else
return null;
}
}
> where test is the value of the test attribute of the when element? what
> form are the test expressions allowed to take?
test="..." for the default method
test="xxx('...')" for the xxx method
note this poses some parsing problems that we might easily solve with
<when method="..." test="...">
where the "default" method is IMPLIED if not expressed.
> they look an awful lot like XPath expressions to me... :)
What do you suggest?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------