Re: XMLForm - xf:repeat tag on DOM Nodes?

[Ivelin Ivanov]

- Original Message -
From: "Josema Alonso" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, November 09, 2002 6:32 PM
Subject: Re: XMLForm - xf:repeat tag on DOM Nodes?


> Stupid me, I sent the code snippet before fix it. That's what I meant
> exactly, and it's working good. I just had some incorrect mappings in the
> model.
>
> You know? It took me a lot of time to understand this whole XMLForms
thingie
> of you. Now that it seems I know what I'm doing I must say I really like
> this approach to forms. Thanks you very much for providing it :-)
>
> Btw, some people are missing a dynamic model, I mean, they say you must
> create it before hand. It would be pretty nice to see it in a next
version,
> sometime, but I can say to those, that using DOM nodes and documents and
> manipulating them inside the action, can give a lot of power to make
things
> dynamic :-)


Yes. This has been requested multiple times.
Please open a feature request ticket in Bugzilla and describe with a few
detailed use cases, what is it exactly that you would like to have.
Others will add their thoughts to the ticket and someone (maybe I) will
eventually implement it.


Thanks,

Ivelin



>
> Thanks again.
>
> - Original Message -
> From: "Ivelin Ivanov" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Saturday, November 09, 2002 8:15 PM
> Subject: Re: XMLForm - xf:repeat tag on DOM Nodes?
>
>
> >
> > You probably meant to use:
> >
> >
> >  
> >   
> >Language (code):
> >
> >   
> >   
> >Description:
> >
> >   
> >  
> >
> > I would also recommend that you use the standard xml:lang attribute
> instead
> > of a non-qualified one.
> >
> >
> >
> > Ivelin
> >
> >
> >
> >
> > - Original Message -
> > From: "Josema Alonso" <[EMAIL PROTECTED]>
> > To: "Cocoon-Users" <[EMAIL PROTECTED]>
> > Sent: Saturday, November 09, 2002 12:40 PM
> > Subject: XMLForm - xf:repeat tag on DOM Nodes?
> >
> >
> > > Dear all,
> > >
> > > I see in thw wizrd demo how the repeat tag is used like this:
> > > 
> > >  
> > >   URL: 
> > >  
> > > 
> > >
> > > In the model bean the favorite is implemented as an array list, so you
> can
> > > iterate through it using the position function and specifying how many
> > items
> > > to display.
> > >
> > > Well, now I got a part of my model implmented as a DOM Node. It seems
> it'w
> > > working right but I can't make the repeat tag to work with it. Let's
say
> I
> > > have something like this:
> > > 
> > > nice table
> > > mesa bonita
> > > 
> > >
> > > I want to display as many textboxes as descriptions, ok? I have tried
> > this,
> > > but unfortunately it is not working. :
> > > 
> > >  
> > >   Language (code):
> > >   
> > >  
> > >  
> > >   Description:
> > >   
> > >  
> > > 
> > >
> > > If I try to access just one description node outside the repeat tag, I
> get
> > > the info correctly. Any ideas?
> > >
> > > Thanks.
> > >
> > >
> > > -
> > > Please check that your question  has not already been answered in the
> > > FAQ before posting. 
> > >
> > > To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> > > For additional commands, e-mail:   <[EMAIL PROTECTED]>
> > >
> >
> >
> > -
> > Please check that your question  has not already been answered in the
> > FAQ before posting. 
> >
> > To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> > For additional commands, e-mail:   <[EMAIL PROTECTED]>
> >
>
>
> -
> Please check that your question  has not already been answered in the
> FAQ before posting. 
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail:   <[EMAIL PROTECTED]>
>


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

[OFF-TOPIC] WAP 2.0 and XHTMLMP vrs. WML

[Antonio A. Gallardo Rivera]

Hi,

I am currently reading "the book" of Carsten and Matthew. I have interest
in the support of the WAP technology and similars with Cocoon. Of course
to use it we must to know this technologies too.

Well, thanks to "the book", I am now buying new books about SVG and
XSL-FO. To learn about this technologies.

Also I made a little research around to find a nice book that will help me
in the Wireless world. I was searching for books in amazon.com. Then I saw
that there is now a new WAP 2.0 (January 2002) that said:

"The WAP 2.0 Application Environment (WAE) has evolved to embrace
developing standards for Internet browser markup language. This has led to
the definition  of the XHTML Mobile Profile (XHTMLMP). XHTMLMP is based on
the modularity framework of the XHTML developed by W3C to replace and
enhance the currently used HTML language common today"

In another paragraph:

"The basic markup language for the WAE in WAP 2.0, namely XHTMLMP, extends
the Basic profile of XHTML as defined in W3C. This core was designed to be
extensible and WAE takes advantage of this capability by defining
additional markup features for enhanced functionality. By using the XHTML
modularization approach, the XHTMLMP language is very extensible,
permitting additional language elements to be added as needed.
Additionally, documents written in the core XHTML Basic language will be
completly operable on the XHTMLMP browser."

Source: http://www.wapforum.org/


That means that we dont need to learn WML1 because XHTMLMP is the future?
What you think?

Please, comments are welcome.

Antonio Gallardo









-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: URL Theory & Best Practices

[Miles Elam]

Nevermind.  I take it all back (well...some of it).  I admit that the 
trailing slash is an artifact of my experience and not of utility.

Damned mailing lists...you can't remove things you wish you hadn't said. 
Accountability's overrated.  ;-)

- Miles

Miles Elam wrote:

Justin Fagnani-Bell wrote:


This is definitely where we differ. I don't see why an intrinsic 
resource should always end in a '/'. If /a/b.pdf is the PDF 
representation then why shouldn't /a/b be the intrinsic resource? The 
only reason I see why the trailing slash is recommended is because 
developers are used to having their URI space tied to their 
filesystem structure with a static server like Apache. The trailing 
slash, from our experience with filesystems,  indicates that 
something is a directory, that it has children. But in a URI a 
resource can be both a viewable resource and a container node at the 
same time. There's certainly nothing stopping /a/b/, /a/b, /a/b.pdf 
and /a/b/c.pdf from all being valid URI's in the same space. To me 
the trailing slash simple indicates that there's more to come at 
lower levels, and the absence of it means the resource is a leaf.

You're right in that it is what we are used to but not necessarily 
because of the filesystem.  I misspoke in this case where /a/b could 
indeed be a resource in some cases.  One major problem lies in clients 
like IE (for better or for worse the dominant viewer) which don't 
always behave correctly even when the correct MIME type is sent.  The 
other is when the resource references other resources.

Take a web article by Oreilly for example.  These articles have 
images, multiple pages, talkbacks, etc.  If /a/b is the intrinsic 
resource, how do we logically access the first figure in that 
article?  How do we access the third page?  Aren't multiple pages just 
another representation of the resource?  PDFs can encompass multiple 
pages.  A web page made for printout would encompass only one long 
page.  Would it be /a/b/printable.html?

Is one more correct than another?  I don't think so -- it seems to 
come down to personal preference, all other things being equal.  I 
think IE would have fewer problems with the slash.  I personally don't 
view the trailing slash as a directory but as a resource collection.  
Perhaps a collection of representations?  But that's just semantics 
and I'm grasping here.

In the example of the Oreilly article, I think that there is more to 
come at the lower levels, there is no absence of lower levels when 
representations are considered lower levels, and that it's a node and 
not a leaf.  I can only think that a resource would be a leaf if it 
and its siblings never have inline constituents like images, multiple 
pages, plugins, etc..




-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: URL Theory & Best Practices

[Miles Elam]

Justin Fagnani-Bell wrote:


This is where we differ slightly.  In my mind /a/b/ is the 
intrinsic resource.  /a/b/index.html is the explicit call for HTML 
represention of /a/b/.  If you redirect a client to /a/b/index.html 
and the client bookmarks it, they are bookmarking the HTML 
representation, not the intrinsic resource.


This is definitely where we differ. I don't see why an intrinsic 
resource should always end in a '/'. If /a/b.pdf is the PDF 
representation then why shouldn't /a/b be the intrinsic resource? The 
only reason I see why the trailing slash is recommended is because 
developers are used to having their URI space tied to their filesystem 
structure with a static server like Apache. The trailing slash, from 
our experience with filesystems,  indicates that something is a 
directory, that it has children. But in a URI a resource can be both a 
viewable resource and a container node at the same time. There's 
certainly nothing stopping /a/b/, /a/b, /a/b.pdf and /a/b/c.pdf from 
all being valid URI's in the same space. To me the trailing slash 
simple indicates that there's more to come at lower levels, and the 
absence of it means the resource is a leaf.

You're right in that it is what we are used to but not necessarily 
because of the filesystem.  I misspoke in this case where /a/b could 
indeed be a resource in some cases.  One major problem lies in clients 
like IE (for better or for worse the dominant viewer) which don't always 
behave correctly even when the correct MIME type is sent.  The other is 
when the resource references other resources.

Take a web article by Oreilly for example.  These articles have images, 
multiple pages, talkbacks, etc.  If /a/b is the intrinsic resource, how 
do we logically access the first figure in that article?  How do we 
access the third page?  Aren't multiple pages just another 
representation of the resource?  PDFs can encompass multiple pages.  A 
web page made for printout would encompass only one long page.  Would it 
be /a/b/printable.html?

Is one more correct than another?  I don't think so -- it seems to come 
down to personal preference, all other things being equal.  I think IE 
would have fewer problems with the slash.  I personally don't view the 
trailing slash as a directory but as a resource collection.  Perhaps a 
collection of representations?  But that's just semantics and I'm 
grasping here.

In the example of the Oreilly article, I think that there is more to 
come at the lower levels, there is no absence of lower levels when 
representations are considered lower levels, and that it's a node and 
not a leaf.  I can only think that a resource would be a leaf if it and 
its siblings never have inline constituents like images, multiple pages, 
plugins, etc..

P.S.  Thank god for the mailing lists.  They actually encourages me 
to write down some of my thoughts.  Even they are off the mark more 
often than not...  Does this make email better than web or simply 
justify the need for more discussion on the web? 


But it apparently has a detrimental effect on my proper use of English 
grammar.  *sigh*

- Miles



-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: how to manage several XMLForms in a sitemap? (it was: dynamically choosing an action at runtime)

[Ivelin Ivanov]

- Original Message -
From: "Josema Alonso" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, November 09, 2002 5:35 PM
Subject: Re: how to manage several XMLForms in a sitemap? (it was:
dynamically choosing an action at runtime)


> > I am not sure if I would do this like you did.
> > There are is a certain lifecycle contract between every Cocoon component
> and
> > the container.
> > By invoking directly you may be violating this contract.
> > I would probably let the sitemap do the forwarding to actions.
> > In your case action sets might be good.
> > http://xml.apache.org/cocoon/userdocs/concepts/actions.html
> I considered them and maybe I'll use them. I'm trying to make a good
> decision.
>
> > Alternatively you can use one dispatcher action which inherits from
> > AbstractXMLFormAction and works directly with the backend based on the
> > requested command.
> I see. Someone pointed this one, too, but I'm that Avalon savvy to
implement
> something like this currently.

Just open org.apache.cocoon.samples.xmlform.WizardAction.java

then look more carefully in webapp/samples/xmlform

>
> > Yet another alternative is for the extending action to return an
> objectmodel
> > parameter which is matched later in the sitemap.
> > 
> >   ...
> >   
> This one sounds new, interesting and easy to code. I'll give it a try :-)
>
> Thank you very much.
>
>
> -
> Please check that your question  has not already been answered in the
> FAQ before posting. 
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail:   <[EMAIL PROTECTED]>
>


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: how to manage several XMLForms in a sitemap? (it was: dynamically choosing an action at runtime)

[Josema Alonso]

> I am not sure if I would do this like you did.
> There are is a certain lifecycle contract between every Cocoon component
and
> the container.
> By invoking directly you may be violating this contract.
> I would probably let the sitemap do the forwarding to actions.
> In your case action sets might be good.
> http://xml.apache.org/cocoon/userdocs/concepts/actions.html
I considered them and maybe I'll use them. I'm trying to make a good
decision.

> Alternatively you can use one dispatcher action which inherits from
> AbstractXMLFormAction and works directly with the backend based on the
> requested command.
I see. Someone pointed this one, too, but I'm that Avalon savvy to implement
something like this currently.

> Yet another alternative is for the extending action to return an
objectmodel
> parameter which is matched later in the sitemap.
> 
>   ...
>   
This one sounds new, interesting and easy to code. I'll give it a try :-)

Thank you very much.


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: XMLForm - xf:repeat tag on DOM Nodes?

[Josema Alonso]

Stupid me, I sent the code snippet before fix it. That's what I meant
exactly, and it's working good. I just had some incorrect mappings in the
model.

You know? It took me a lot of time to understand this whole XMLForms thingie
of you. Now that it seems I know what I'm doing I must say I really like
this approach to forms. Thanks you very much for providing it :-)

Btw, some people are missing a dynamic model, I mean, they say you must
create it before hand. It would be pretty nice to see it in a next version,
sometime, but I can say to those, that using DOM nodes and documents and
manipulating them inside the action, can give a lot of power to make things
dynamic :-)

Thanks again.

- Original Message -
From: "Ivelin Ivanov" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, November 09, 2002 8:15 PM
Subject: Re: XMLForm - xf:repeat tag on DOM Nodes?


>
> You probably meant to use:
>
>
>  
>   
>Language (code):
>
>   
>   
>Description:
>
>   
>  
>
> I would also recommend that you use the standard xml:lang attribute
instead
> of a non-qualified one.
>
>
>
> Ivelin
>
>
>
>
> - Original Message -
> From: "Josema Alonso" <[EMAIL PROTECTED]>
> To: "Cocoon-Users" <[EMAIL PROTECTED]>
> Sent: Saturday, November 09, 2002 12:40 PM
> Subject: XMLForm - xf:repeat tag on DOM Nodes?
>
>
> > Dear all,
> >
> > I see in thw wizrd demo how the repeat tag is used like this:
> > 
> >  
> >   URL: 
> >  
> > 
> >
> > In the model bean the favorite is implemented as an array list, so you
can
> > iterate through it using the position function and specifying how many
> items
> > to display.
> >
> > Well, now I got a part of my model implmented as a DOM Node. It seems
it'w
> > working right but I can't make the repeat tag to work with it. Let's say
I
> > have something like this:
> > 
> > nice table
> > mesa bonita
> > 
> >
> > I want to display as many textboxes as descriptions, ok? I have tried
> this,
> > but unfortunately it is not working. :
> > 
> >  
> >   Language (code):
> >   
> >  
> >  
> >   Description:
> >   
> >  
> > 
> >
> > If I try to access just one description node outside the repeat tag, I
get
> > the info correctly. Any ideas?
> >
> > Thanks.
> >
> >
> > -
> > Please check that your question  has not already been answered in the
> > FAQ before posting. 
> >
> > To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> > For additional commands, e-mail:   <[EMAIL PROTECTED]>
> >
>
>
> -
> Please check that your question  has not already been answered in the
> FAQ before posting. 
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail:   <[EMAIL PROTECTED]>
>


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: URL Theory & Best Practices

[Justin Fagnani-Bell]

On Saturday, November 9, 2002, at 12:08  PM, Miles Elam wrote:


Tony Collen wrote:


Comments inline...

Miles Elam wrote:


But can't delivered types differ by the incoming client?


Yes, but a problem then arises when someone is using IE and they want 
a PDF, when your user-agent rules will only serve a PDF for FooCo PDF 
Browser 1.0.  IMO browsers should respect the mime-type header.  I 
believe the mime-type headers is very useful when you want to use 
something like a PHP script to send an image or a .tar.gz file.  In 
fact, it's essential for it to work, otherwise the browser interprets 
the data as garbage.

No, that's wasn't my intention at all.  If someone is using IE and 
they want a pdf (not a default expectation for that particular browser 
like html or xml), then the URL they would get directed to would be 
*.pdf. This is not the intrinsic resource.  You are explicitly asking 
for the PDF representation of that resource.

If the browser's default expectation is PDF (like in your FooCo PDF 
Browser 1.0 example), the trailing slash resource would give it PDF. 
However, it could still be pointed to *.pdf if you wanted to make it 
explicit.

This is very well put Miles, and was my intention with the previous 
email I wrote. Content negotiation and file extensions can (and IMO 
should) exist side-by-side. There is no precedent for a browser 
changing its accept header on a per-request basis, as someone 
suggested, not is there a way to specify this behavior in a hyper-link. 
If you have a link on a site that says "Click here for a PDF" then I 
would expect that the URI would end in .pdf, at least that's what makes 
the most sense to me.


In those cases where only PDF is available (common when it's not 
dynamically generated), I see no reason why the URI wouldn't be *.pdf.

Exactly.


This is where we differ slightly.  In my mind /a/b/ is the intrinsic 
resource.  /a/b/index.html is the explicit call for HTML 
represention of /a/b/.  If you redirect a client to /a/b/index.html 
and the client bookmarks it, they are bookmarking the HTML 
representation, not the intrinsic resource.

This is definitely where we differ. I don't see why an intrinsic 
resource should always end in a '/'. If /a/b.pdf is the PDF 
representation then why shouldn't /a/b be the intrinsic resource? The 
only reason I see why the trailing slash is recommended is because 
developers are used to having their URI space tied to their filesystem 
structure with a static server like Apache. The trailing slash, from 
our experience with filesystems,  indicates that something is a 
directory, that it has children. But in a URI a resource can be both a 
viewable resource and a container node at the same time. There's 
certainly nothing stopping /a/b/, /a/b, /a/b.pdf and /a/b/c.pdf from 
all being valid URI's in the same space. To me the trailing slash 
simple indicates that there's more to come at lower levels, and the 
absence of it means the resource is a leaf.

As for redirects, I don't see it being too much of a problem with more 
recent protocols. Also it should only happen when a visitor is being 
referred from an external page, since all the URL's in your site should 
be in the correct form. If you are linking to the intrinsic resource, I 
don't see the need for a redirect (as long as the browser correctly 
understands the mime-type header), so I don't see a problem with 
bookmarking.

- Miles

P.S.  Thank god for the mailing lists.  They actually encourages me to 
write down some of my thoughts.  Even they are off the mark more often 
than not...  Does this make email better than web or simply justify 
the need for more discussion on the web?

Here here. I say both, linear discussion is good, so is collaboration. 
A discussion board combined with a wiki would be awesome. Discuss a 
topic and collaborate on a document summing up the ideas at the same 
time. Hmm... Cocoon could do that :)

-Justin


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: URL Theory & Best Practices

[Antonio A. Gallardo Rivera]

Erik Bruchez dijo:
>> Uh-oh I'm catching some bad vibs... Can someone do me a favour of
>> going to http://www.kjernsmo.net/ with IE6 and see what happens?
>>
> I don't think IE ignores the content-type header. It may be more lax
> than NS when it sees a file extension, but the home page of your site
> does not have any. The page displays fine with IE 6.
>
> -Erik

I talked about the case of PDF serialization!

Antonio Gallardo
>
>
>
> -
> Please check that your question  has not already been answered in the
> FAQ before posting. 
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail:   <[EMAIL PROTECTED]>




-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: URL Theory & Best Practices

[Antonio A. Gallardo Rivera]

I dont know if MS IE 6.0 is standard compliant of not. I dont care. I
think MS IE try to be compliant. I develop under Linux. But I know too
that MS IE 6.0 is the most used browser in the world. Then? I also check
the MS IE presentation.

I dont want to continue this polemic about if this will work or not. Make
a simple example and you will see that:

"The use of PDF filename without extension in the MS IE 6.0 SP1 currently
does not work. This is a fact!

Maybe in the future we can make use of the URI without extension. But I am
developing for current browser. Every developer must take care of that.

Again, I agree with the theory of not use the extension. But for now. It
does not work for PDF case under MS Windows.

I already make use of the FOP and PDF serialization. Why make some wrong
afirmation to people (mainly newbies) about how to make it when it does
not work?

At the end, please dont take me wrong. I am just trying to help. :-D

Regards,

Antonio Gallardo.

Kjetil Kjernsmo dijo:
> On Saturday 09 November 2002 23:41, Antonio A. Gallardo Rivera wrote:
>> The true is that I wrote. If you dont believe me, I recommend you to
>> check the archive of this mailing list. This was not my fault. Not
>> only I found this error many other people had the same problem with IE
>> 6.0 SP1. I fighted with generation of PDF the content for a day after
>> I realize that the extension must be .pdf or it will not work!
>>
>> This is why I told you about the fine theory and the cruel reality.
>> :-D
>
> Uh-oh I'm catching some bad vibs... Can someone do me a favour of
> going to http://www.kjernsmo.net/ with IE6 and see what happens?
>
> The mainpage isn't a big thing, it is pure XHTML, but per the XHTML 1.0
> spec, it is served as text/html, but it is using simple Apache content
> negotation to set that. So, I've got this bad feeling that IE is going
> to ignore the content-type header and just list it as raw XML with no
> stylesheet, because that is what would be a logical consequence of what
> you write. But I can't for the life of me understand how it can be
> standards-compliant...
>
> Best,
>
> Kjetil
> --
> Kjetil Kjernsmo
> Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer
> [EMAIL PROTECTED]  [EMAIL PROTECTED]  [EMAIL PROTECTED]
> Homepage: http://www.kjetil.kjernsmo.net/
>
>
> -
> Please check that your question  has not already been answered in the
> FAQ before posting. 
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail:   <[EMAIL PROTECTED]>




-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: URL Theory & Best Practices

[Kjetil Kjernsmo]

On Saturday 09 November 2002 23:57, Barbara Post wrote:
> Oh, I get 406 code, I didn't know this one !!
> I have IE6 SP1 on Windows 2000 Pro.

Hehe, oh well, that's another browser quirk, but a much less serious so. 
I use language negotation too, so what everybody _should_ do is go into 
their settings and make sure they enable all languages they know how to 
read... Check out http://www.debian.org/intro/cn for a howto... 
Lacking that, browser vendors should add an *;q=0.001 to their language 
strings to avoid this error, but that's a lot more IMHO than the other 
things I've written in this thread... :-) 

I'd tried to talk the Mozilla folks into that in Bug 55800, 
http://bugzilla.mozilla.org/show_bug.cgi?id=55800 and the fact that 
you're getting 406 is proof that they are wrong... :-)
Anyway, I've been logging language settings for a long time on one of my 
sites, and it was in fact very few users who had browsers were it would 
break, and language negotation is quite cool, so I decided to use it. 
Besides, those users who have it wrong could be catered for with a good 
error handler, if I had bothered... :-) 

Thanks for checking! :-)

Best,

Kjetil
-- 
Kjetil Kjernsmo
Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer
[EMAIL PROTECTED]  [EMAIL PROTECTED]  [EMAIL PROTECTED]
Homepage: http://www.kjetil.kjernsmo.net/


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: URL Theory & Best Practices

[Barbara Post]

Oh, I get 406 code, I didn't know this one !!
I have IE6 SP1 on Windows 2000 Pro.

Babs
--
website : www.babsfrance.fr.st
ICQ : 135868405
- Original Message -
From: "Kjetil Kjernsmo" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, November 09, 2002 11:42 PM
Subject: Re: URL Theory & Best Practices


>
> Uh-oh I'm catching some bad vibs... Can someone do me a favour of
> going to http://www.kjernsmo.net/ with IE6 and see what happens?
>
> The mainpage isn't a big thing, it is pure XHTML, but per the XHTML 1.0
> spec, it is served as text/html, but it is using simple Apache content
> negotation to set that. So, I've got this bad feeling that IE is going
> to ignore the content-type header and just list it as raw XML with no
> stylesheet, because that is what would be a logical consequence of what
> you write. But I can't for the life of me understand how it can be
> standards-compliant...
>
> Best,
>
> Kjetil
> --
> Kjetil Kjernsmo
> Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer
> [EMAIL PROTECTED]  [EMAIL PROTECTED]  [EMAIL PROTECTED]
> Homepage: http://www.kjetil.kjernsmo.net/
>
>
> -
> Please check that your question  has not already been answered in the
> FAQ before posting. 
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail:   <[EMAIL PROTECTED]>
>
>
> __
> Modem offert : 150,92 euros remboursés sur le Pack eXtense de Wanadoo !
> Haut débit à partir de 30 euros/mois : http://www.ifrance.com/_reloc/w


__
Modem offert : 150,92 euros remboursés sur le Pack eXtense de Wanadoo ! 
Haut débit à partir de 30 euros/mois : http://www.ifrance.com/_reloc/w


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: URL Theory & Best Practices

[Erik Bruchez]

Uh-oh I'm catching some bad vibs... Can someone do me a favour of
going to http://www.kjernsmo.net/ with IE6 and see what happens?


I don't think IE ignores the content-type header. It may be more lax 
than NS when it sees a file extension, but the home page of your site 
does not have any. The page displays fine with IE 6.

-Erik



-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: URL Theory & Best Practices

[Kjetil Kjernsmo]

On Saturday 09 November 2002 23:41, Antonio A. Gallardo Rivera wrote:
> The true is that I wrote. If you dont believe me, I recommend you to
> check the archive of this mailing list. This was not my fault. Not
> only I found this error many other people had the same problem with
> IE 6.0 SP1. I fighted with generation of PDF the content for a day
> after I realize that the extension must be .pdf or it will not work!
>
> This is why I told you about the fine theory and the cruel reality.
> :-D

Uh-oh I'm catching some bad vibs... Can someone do me a favour of 
going to http://www.kjernsmo.net/ with IE6 and see what happens?

The mainpage isn't a big thing, it is pure XHTML, but per the XHTML 1.0 
spec, it is served as text/html, but it is using simple Apache content 
negotation to set that. So, I've got this bad feeling that IE is going 
to ignore the content-type header and just list it as raw XML with no 
stylesheet, because that is what would be a logical consequence of what 
you write. But I can't for the life of me understand how it can be 
standards-compliant...  

Best,

Kjetil
-- 
Kjetil Kjernsmo
Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer
[EMAIL PROTECTED]  [EMAIL PROTECTED]  [EMAIL PROTECTED]
Homepage: http://www.kjetil.kjernsmo.net/


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: Umlauts in cocoon 2.0.2

[Antonio A. Gallardo Rivera]

I recommmend you to check the mail archives fo this list with the keyword
"Umlauts". There is a summary about this problem.

Antonio Gallardo

Braun dijo:
> I have the problem with german Umlauts in request parameters.
> When I transfer german Umlauts by request paramaters cocoon doesn't
> decode the Umlauts encoding when I use these Umlauts in my xml-documents
>  or stylesheets.
> I set already all my encodings to ISO-8859-1.
>
>
>
>
> -
> Please check that your question  has not already been answered in the
> FAQ before posting. 
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail:   <[EMAIL PROTECTED]>




-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: URL Theory & Best Practices

[Antonio A. Gallardo Rivera]

The true is that I wrote. If you dont believe me, I recommend you to check
the archive of this mailing list. This was not my fault. Not only I found
this error many other people had the same problem with IE 6.0 SP1. I
fighted with generation of PDF the content for a day after I realize that
the extension must be .pdf or it will not work!

This is why I told you about the fine theory and the cruel reality. :-D


Antonio Gallardo.

Kjetil Kjernsmo dijo:
> On Saturday 09 November 2002 21:33, Miles Elam wrote:
>> Antonio A. Gallardo Rivera wrote:
>> >Kjetil Kjernsmo dijo:
>> >>On Thursday 07 November 2002 23:57, Tony Collen wrote:
>> >>>However, later I realize that using file extensions is "bad".
>> >>> Read http://www.alistapart.com/stories/slashforward/ for more info
>> on this idea.
>> >
>> >I know about that. The theory is fine, but in the real world... Are
>> > you tried to open a PDF file without the .pdf extension with MS IE
>> 6.0 SP1?
>
> No, I have barely touched IE since 3.0.
>
>> > It does not work. MS IE relays mainly on the extension of
>> > the file to open a pdf file.
>
> What?!? What you're saying is that IE is ignoring the content-type?
> That's just incredibly silly...
>
>> How we can address this? I already
>> > know that Carsten and Mathew in his book dont recommend the use of
>> extension and I agree. But how we can tell MS Internet Explorer
>> about that?
>>
>> PDF isn't IE's normal method of receiving information (ease of use
>> with Acrobat aside).  If you specifically want the PDF
>> representation, specify *.pdf.  If what you want is the resource, then
>> you aren't asking specifically for PDF.  If all you have is PDF and
>> PDF is the only representation, then having your URL specify that you
>> are serving PDF hurts no one and corrupts no URLs.
>
> Yes it does! What representation is chosen should only depend on the
> Accept header, and what the UA should do with a file it receives should
> have nothing to do with the filename whatsoever, it should be based on
> the Content-Type-header in the response, solely. It's been a while
> since I read the HTTP 1.1 spec, but IIRC, it is pretty clearly spelled
> out there. It should only depend on the MIME-type. On the server and
> client sides, separately, how it is done is of no concern of anybody,
> but that the client depends on what file extension the server uses has
> to be a violation of the spec, again IIRC.
>
> During content negotation, an extensionless URL should be responded to
> with 200 if the server has a representation which is acceptable
> according to the client's Accept*-headers, with a Location-header
> saying where to find the best file, and that file may well have a .pdf
> extension. If no appropriate representation is found, the server should
> respond with 406.
>
> 
>
> Cheers,
>
> Kjetil
> --
> Kjetil Kjernsmo
> Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer
> [EMAIL PROTECTED]  [EMAIL PROTECTED]  [EMAIL PROTECTED]
> Homepage: http://www.kjetil.kjernsmo.net/
>
>
> -
> Please check that your question  has not already been answered in the
> FAQ before posting. 
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail:   <[EMAIL PROTECTED]>




-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: Serializer for d-o-e?

[Sylvain Wallez]

J.Pietschmann wrote:

> Lenz, Evan wrote:
>
>> I understand why Cocoon disables the use of disable-output-escaping
>> in XSLT.
>> However, in my current project, which involves parsing XML results from
>> Google containing escaped (and non-well-formed) HTML, I need to find
>> a way
>> to disable output escaping for certain sections of text, perhaps
>> based on
>> the presence of a special attribute or PI that I can generate when
>> necessary. Does Cocoon provide a way of parameterizing an existing
>> serializer to do this? Has anyone implemented such a serializer? I would
>> think that such a customization of an existing XML serializer should be
>> pretty simple, but the Cocoon serialization framework is so abstract
>> that
>> I'm having trouble finding the right code to extend or modify.
>
>
> The answer is quite simple: you can't. D-o-e only works if the
> XSLT processor serializes the result itself, the information
> which text nodes are supposed to be d-o-e'd on output is not
> transported through the SAX pipelines Cocoon uses for plumbing
> it's components.


JAXP provides two special PIs to handle the case when serialization
isn't performed by the XSLT engine :
-  to start d-o-e and
-  to stop it.

See also
http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-commons/java/external/src/javax/xml/transform/Result.java?rev=1.2

Hope this helps, but use it wisely !

--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }





-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: Testing for the *presence* of a particular request parameter

[Antonio A. Gallardo Rivera]

Lenz, Evan dijo:
> I need to test for the presence of a particular request parameter. In
> particular, I want to write my sitemap such that the following URLs will
> behave as described:
>
> /search -> loads the search page
> /search?q=blah  -> displays search results
> /search?q=  -> empty results, or the search page itself (don't care)
>
> I know how to use the request-parameter selector (which tests for
> particular parameter *values*), but I don't know how to test for the
> *presence* of a particular parameter (or to test for a non-empty value).
> Can
> request-parameter do this, or do I need to use something else?
Look for the request matcher: matches a request parameters given as a
pattern. If the parameter exists, its value is available for later
substitution.

Antonio Gallardo
>
> Thanks,
> Evan
>
> -
> Please check that your question  has not already been answered in the
> FAQ before posting. 
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail:   <[EMAIL PROTECTED]>




-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: Accessing the output of a modular db action in xsl

[Phil Craven]

I tried that as well, and only row-count would come through, I was unable to
get the selected parameters even though I used 

so what would the correct map:parameter look like to get at the output of a
mod-db select.

Just to reiterate I appologize for being dense and greatly appreciate the
 help (in case I forgot to mention earlier)

On Tuesday 05 November 2002 01:39 pm, Christian Haul wrote:
> On 04.Nov.2002 -- 07:43 PM, Phil Craven wrote:
> > here is the sitemap segment that shows what I am trying to do.
> >
> >  
> > 
> >   
> >   
> >   
> >   
> > 
> > true
> >   
> >   
> > 
> > 
> > 
> >   
> >
> > The kicker is that I can see the values in the logs, but I cannot see the
> > values reflected in the xsl.  On a related not, if I add row-count in as
> > a parameter, then it will show up in the xsl, but no other values will.
>
> Phil, what do you mean with "not in the xsl"? Which xsl?
> Sitemap variables are never automatically propagated to any other
> component. This needs to be done explicitly e.g. using 
>
> Results from a database action are available as request attributes as well.
>
>   Chris.

---


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: URL Theory & Best Practices

[Kjetil Kjernsmo]

On Saturday 09 November 2002 21:33, Miles Elam wrote:
> Antonio A. Gallardo Rivera wrote:
> >Kjetil Kjernsmo dijo:
> >>On Thursday 07 November 2002 23:57, Tony Collen wrote:
> >>>However, later I realize that using file extensions is "bad". 
> >>> Read http://www.alistapart.com/stories/slashforward/ for more
> >>> info on this idea.
> >
> >I know about that. The theory is fine, but in the real world... Are
> > you tried to open a PDF file without the .pdf extension with MS IE
> > 6.0 SP1?

No, I have barely touched IE since 3.0.

> > It does not work. MS IE relays mainly on the extension of
> > the file to open a pdf file. 

What?!? What you're saying is that IE is ignoring the content-type? 
That's just incredibly silly... 

> How we can address this? I already
> > know that Carsten and Mathew in his book dont recommend the use of
> > extension and I agree. But how we can tell MS Internet Explorer
> > about that?
>
> PDF isn't IE's normal method of receiving information (ease of use
> with Acrobat aside).  If you specifically want the PDF
> representation, specify *.pdf.  If what you want is the resource,
> then you aren't asking specifically for PDF.  If all you have is PDF
> and PDF is the only representation, then having your URL specify that
> you are serving PDF hurts no one and corrupts no URLs.

Yes it does! What representation is chosen should only depend on the 
Accept header, and what the UA should do with a file it receives should 
have nothing to do with the filename whatsoever, it should be based on 
the Content-Type-header in the response, solely. It's been a while 
since I read the HTTP 1.1 spec, but IIRC, it is pretty clearly spelled 
out there. It should only depend on the MIME-type. On the server and 
client sides, separately, how it is done is of no concern of anybody, 
but that the client depends on what file extension the server uses has 
to be a violation of the spec, again IIRC. 

During content negotation, an extensionless URL should be responded to 
with 200 if the server has a representation which is acceptable 
according to the client's Accept*-headers, with a Location-header 
saying where to find the best file, and that file may well have a .pdf 
extension. If no appropriate representation is found, the server should 
respond with 406. 



Cheers,

Kjetil
-- 
Kjetil Kjernsmo
Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer
[EMAIL PROTECTED]  [EMAIL PROTECTED]  [EMAIL PROTECTED]
Homepage: http://www.kjetil.kjernsmo.net/


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: URL Theory & Best Practices

[Miles Elam]

Antonio A. Gallardo Rivera wrote:


Kjetil Kjernsmo dijo:
 

On Thursday 07 November 2002 23:57, Tony Collen wrote:
   

However, later I realize that using file extensions is "bad".  Read
http://www.alistapart.com/stories/slashforward/ for more info on this
idea.
 


I know about that. The theory is fine, but in the real world... Are you
tried to open a PDF file without the .pdf extension with MS IE 6.0 SP1? It
does not work. MS IE relays mainly on the extension of the file to open a
pdf file. How we can address this? I already know that Carsten and Mathew
in his book dont recommend the use of extension and I agree. But how we
can tell MS Internet Explorer about that?


PDF isn't IE's normal method of receiving information (ease of use with 
Acrobat aside).  If you specifically want the PDF representation, 
specify *.pdf.  If what you want is the resource, then you aren't asking 
specifically for PDF.  If all you have is PDF and PDF is the only 
representation, then having your URL specify that you are serving PDF 
hurts no one and corrupts no URLs.

- Miles



-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Umlauts in cocoon 2.0.2

[Braun]

I have the problem with german Umlauts in request parameters.
When I transfer german Umlauts by request paramaters cocoon doesn't 
decode the Umlauts encoding when I use these Umlauts in my xml-documents 
or stylesheets.
I set already all my encodings to ISO-8859-1.




-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Testing for the *presence* of a particular request parameter

[Lenz, Evan]

I need to test for the presence of a particular request parameter. In
particular, I want to write my sitemap such that the following URLs will
behave as described:

/search -> loads the search page
/search?q=blah  -> displays search results
/search?q=  -> empty results, or the search page itself (don't care)

I know how to use the request-parameter selector (which tests for particular
parameter *values*), but I don't know how to test for the *presence* of a
particular parameter (or to test for a non-empty value). Can
request-parameter do this, or do I need to use something else?

Thanks,
Evan

-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: URL Theory & Best Practices

[Antonio A. Gallardo Rivera]

Kjetil Kjernsmo dijo:
> Hi!
>
> Interesting thread! Most things has been said allready, but I'll just
> add a little .02 (whatever currency) :-)
>
> On Thursday 07 November 2002 23:57, Tony Collen wrote:
>
>> However, later I realize that using file extensions is "bad".  Read
>> http://www.alistapart.com/stories/slashforward/ for more info on this
>> idea.

I know about that. The theory is fine, but in the real world... Are you
tried to open a PDF file without the .pdf extension with MS IE 6.0 SP1? It
does not work. MS IE relays mainly on the extension of the file to open a
pdf file. How we can address this? I already know that Carsten and Mathew
in his book dont recommend the use of extension and I agree. But how we
can tell MS Internet Explorer about that?

Antonio Gallardo.
>
> The article is interesting, but a little too narrow. Indeed, using file
> extensions are Bad[tm] for URIs because you tie the address to a
> specific technology, which you may not be using in some years. For that
> reason not changing the default "cocoon" in Cocoon URIs are also a  Bad
> Thing[tm].
>
> The authorative reference on this topic is TimBL's rant "Cool URIs don't
>  change": http://www.w3.org/Provider/Style/URI :-)
>
> So, using directories for everything is one possibility, and if you do,
> make sure to include the trailing /, to avoid useless 301 redirects.
> Another option is to use Content Negotation, which is well defined in
> HTTP 1.1 (and earlier, IIRC), it's weird that it isn't more widely
> used.
>
> But, both content negotation and using directories for everything are
> both solutions that exists mainly because URIs have been so strongly
> tied to the file system of the server, and the mentioned article seems
> to take as granted that this connection is a necessity, but as Cocoon
> proves, this is not so. Just use sensible matches. It also means that
> requiring a trailing slash on every URI is a bit too much, I only do
> that if there is logically a hierarchal substructure.
>
> As for the problem of serving different formats to the client, I really
> have no good solution. What the user agents should do, was to let the
> user easily manipulate the Accept-header, so if the user wants a
> PDF-file, he would send only application/pdf in the Accept header, and
> the server would know that the user wanted a PDF-file, and send that.
> Given that it doesn't exist, appending the type to the URI is probably
> not too bad.
>
> Best,
>
> Kjetil
> --
> Kjetil Kjernsmo
> Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer
> [EMAIL PROTECTED]  [EMAIL PROTECTED]  [EMAIL PROTECTED]
> Homepage: http://www.kjetil.kjernsmo.net/
>
>
> -
> Please check that your question  has not already been answered in the
> FAQ before posting. 
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail:   <[EMAIL PROTECTED]>




-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: URL Theory & Best Practices

[Miles Elam]

Tony Collen wrote:


Comments inline...

Miles Elam wrote:


But can't delivered types differ by the incoming client?


Yes, but a problem then arises when someone is using IE and they want 
a PDF, when your user-agent rules will only serve a PDF for FooCo PDF 
Browser 1.0.  IMO browsers should respect the mime-type header.  I 
believe the mime-type headers is very useful when you want to use 
something like a PHP script to send an image or a .tar.gz file.  In 
fact, it's essential for it to work, otherwise the browser interprets 
the data as garbage. 

No, that's wasn't my intention at all.  If someone is using IE and they 
want a pdf (not a default expectation for that particular browser like 
html or xml), then the URL they would get directed to would be *.pdf. 
This is not the intrinsic resource.  You are explicitly asking for the 
PDF representation of that resource.

If the browser's default expectation is PDF (like in your FooCo PDF 
Browser 1.0 example), the trailing slash resource would give it PDF. 
However, it could still be pointed to *.pdf if you wanted to make it 
explicit.

In those cases where only PDF is available (common when it's not 
dynamically generated), I see no reason why the URI wouldn't be *.pdf. 
In fact, if in the future more presentation types are added, a special 
case for *.pdf to return a static resource and all other variations 
being dynamically generated (or some other mixing and matching) would 
still be valid and a stable URI space.

As far as a php script returning an image, that's fine, but if the URL 
ends with (or even contains) any reference to "php", you are tying your 
URI to a particular technology/delivery method.  With Cocoon, why not 
map /foo/bar/alpha.png to the PHP script that returns a PNG image?  In 
this case, I'm not advocating the trailing slash.  I am advocating that 
you not have PHP even mentioned in the URL.  In this case, the resource 
is a PNG image without regard to client -- have the URL reflect this.

This is where we differ slightly.  In my mind /a/b/ is the intrinsic 
resource.  /a/b/index.html is the explicit call for HTML represention 
of /a/b/.  If you redirect a client to /a/b/index.html and the client 
bookmarks it, they are bookmarking the HTML representation, not the 
intrinsic resource.  I understand the efficiency issues, but a user 
agent match when viewed in the context of sitemap matches, 
server-side logic, servlet request and response object creation and 
other assorted methods calls is just a couple of string comparisons.

This is pretty much the original problem I was trying to solve.  Sure, 
having a clean URL space that always ends in a / is useful, but if you 
look at how that would work on the server, side, it means you create a 
physical directory for each page and then create an index.html.  You 
have tons of files named index.html on your web server, but at least 
it's all organized with the directories. 

Hmmm...  Why is it that your physical directory structure must have 
ANYTHING to do with the URL?  This flies right in the face of the reason 
for Cocoon's sitemap and the resources made available from Apache's 
httpd.conf.  You would indeed have many URLs that point to a resource 
called index.html, but your filesystem need not have any.  Your 
filesystem could be flat without any directories at all.  It could be 
replaced with a database.  ...or LDAP or xmldb or PHP...

If your filesystem is to be 1:1 with your URLs, why use Cocoon and a 
servlet engine at all?  A flat file webserver would serve things much 
faster.  The reason I want to use Cocoon is that it makes things 
*better* and not faster -- although I have methods for getting extra speed.

In my opinion, URLs should not change.


As further explained at http://www.useit.com/alertbox/990321.html 
The rundown:

   - URLs should not change
   - URLs are easy to remember (and therefore are organized logically)
   - URLs are easy to type and are generally all in lowercase

That is one of the main things that drew me to Cocoon: URI 
abstraction.  Once the URL is abstracted enough to act as a true URI, 
it can start acting as a true indentifier instead of an ad hoc, vague 
gobbledygook.  Of course this also assumes that the URL/URI remains 
set in stone and not a moving target.


Yes! This is exactly the conclusion I was coming to on my own. URIs 
are no more than data abstractions.  They usually provide a view to 
some data, and more often than not, a URL on a web server directly 
correlates with a physical file on a disk (e.g. index.html).  Cocoon 
allows one to create a purely virtual URL space in which no real files 
on the server could exist.  It probably doesn't matter how the 
underlying data is abstracted, whether it be a one-to-one correlation 
to a directory tree on a disk somewhere, or an xpath statement into an 
xml file, or arguments to a CGI script that accesses a database 
depending on the order of the items in the request. Imagine a request 
for

Re: XMLForm - xf:repeat tag on DOM Nodes?

[Ivelin Ivanov]

You probably meant to use:


 
  
   Language (code):
   
  
  
   Description:
   
  
 

I would also recommend that you use the standard xml:lang attribute instead
of a non-qualified one.



Ivelin




- Original Message -
From: "Josema Alonso" <[EMAIL PROTECTED]>
To: "Cocoon-Users" <[EMAIL PROTECTED]>
Sent: Saturday, November 09, 2002 12:40 PM
Subject: XMLForm - xf:repeat tag on DOM Nodes?


> Dear all,
>
> I see in thw wizrd demo how the repeat tag is used like this:
> 
>  
>   URL: 
>  
> 
>
> In the model bean the favorite is implemented as an array list, so you can
> iterate through it using the position function and specifying how many
items
> to display.
>
> Well, now I got a part of my model implmented as a DOM Node. It seems it'w
> working right but I can't make the repeat tag to work with it. Let's say I
> have something like this:
> 
> nice table
> mesa bonita
> 
>
> I want to display as many textboxes as descriptions, ok? I have tried
this,
> but unfortunately it is not working. :
> 
>  
>   Language (code):
>   
>  
>  
>   Description:
>   
>  
> 
>
> If I try to access just one description node outside the repeat tag, I get
> the info correctly. Any ideas?
>
> Thanks.
>
>
> -
> Please check that your question  has not already been answered in the
> FAQ before posting. 
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail:   <[EMAIL PROTECTED]>
>


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

XMLForm - xf:repeat tag on DOM Nodes?

[Josema Alonso]

Dear all,

I see in thw wizrd demo how the repeat tag is used like this:

 
  URL: 
 


In the model bean the favorite is implemented as an array list, so you can
iterate through it using the position function and specifying how many items
to display.

Well, now I got a part of my model implmented as a DOM Node. It seems it'w
working right but I can't make the repeat tag to work with it. Let's say I
have something like this:

nice table
mesa bonita


I want to display as many textboxes as descriptions, ok? I have tried this,
but unfortunately it is not working. :

 
  Language (code):
  
 
 
  Description:
  
 


If I try to access just one description node outside the repeat tag, I get
the info correctly. Any ideas?

Thanks.


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Cocoon XSL performance in Tomcat vs Weblogic

[Ulf Åkerberg]

 

 

In our development environment
with Cocoon in Tomcat XSL processing is  fast, the same application deployed in Weblogic 6.1 SP3 takes about 5 times more time to do the XSL part. 

 

In Tomcat it takes about 1
second , in Weblogic 5 seconds on a much faster
machine. Other operations runs faster, but the XSL
processing is a lot slower. We use exactly the same Xalan
version 2.4.0 in both cases. The Cocoon version is 2.02.

 

Any ideas ?

 

 

Regards

 

 

Ulf

Resin (parser?) problem

[Danny Ayers]

Hi,

I've got a problem getting Cocoon 2 (from the bin download) running on Resin
(2.1 I think). A Tomcat install of the same download works (mostly) ok. I
followed the appropriate instructions on a local install and got the error
below when I pointed a browser at ../cocoon. I'm guessing this is related to
the parser used, although I've done the swap to Xerces suggested in the
instructions, maybe it's picking up something else from my classpath?

Not long ago I managed to get some Batik-based material working by adding
the following to the  section of web.xml :



but I can't find a variation on this that helps with the current problem.
Ideally I want to be able to specify the necessary properties on a per-app
basis, as I don't have admin privilege on a live server I want to use - I
can't change anything system-wide or even restart Resin.

Incidentally, does anyone know offhand how the parser for Batik is worked
out in Cocoon - is Xerces somehow used there too?

Cheers,
Danny.

In browser:
java.lang.NullPointerException: Null content handler
at
org.xml.sax.helpers.XMLFilterImpl.setContentHandler(XMLFilterImpl.java:307)
at
org.apache.cocoon.components.language.markup.LogicsheetCodeGenerator.addLogi
csheet(LogicsheetCodeGenerator.java:98)
at
org.apache.cocoon.components.language.markup.AbstractMarkupLanguage.addLogic
sheetsToGenerator(AbstractMarkupLanguage.java:304)
...

In console:
com.caucho.xsl.XslParseException:
jar:file:/C:/resin-2.1.4/webapps/cocoon/WEB-IN
F/lib/cocoon-2.0.jar!/org/apache/cocoon/components/language/markup/sitemap/j
ava/
sitemap.xsl:429: `hasSubstitutions' is not a static method in
`org.apache.cocoon
.sitemap.XSLTFactoryLoader' in XSLTFactoryLoader:hasSubstitutions(@pattern)
at com.caucho.xsl.Generator.error(Generator.java:2143)
at com.caucho.xsl.Generator.error(Generator.java:2120)
at com.caucho.xsl.Generator.parseExpr(Generator.java:2113)
...

---
Danny Ayers

Semantic Web Log :
http://www.citnames.com/blog



-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: Redirect in XSP

[Ludovic de Beaurepaire]

Hi Neil,

It is not very clean, but if you don't find another solution, you can read
in you Action the file content/table_names.xml to find your URL (if it is a
static file, you do it once). You can so add it in a sitemap parameter.

Ludovic

- Original Message -
From: "Neil A" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, November 09, 2002 5:06 PM
Subject: Re: Redirect in XSP


> Thanks Joerg and Artur, but in my case I'm building for WAP.
> Unfortunately the WML equivalent of your client side redirect crashes
> early Nokia 7110 phones.
>
> I really want to use  but my URL is in the XML of the
> pipeline and I can't get it into a sitemap parameter:
>
> 
> 
> 
> 
> 
> 
>
> 
>
> 
> 
>
> Actions can't seem to read or transform the pipeline xml, they can only
> read and act on request parameters.  XSLT transformers can't create
> sitemap parameters.  So I'm a bit stuck.  Can anyone fill in the gap?
>
> Thanks,
>
> Neil.
>
>
> On Saturday, November 9, 2002, at 03:23 AM, Artur Bialecki wrote:
>
> >
> >> Who should close the  element? The transformer can not send an
> >> endElement() until everything inside is processed. Of course you have
> > to
> >
> > Ofcourse, I don't know what I was thinking.
> >
> >> Does this make it a bit clearer? Everybody can of course improve my
> >
> > This makes it very clear.
> >
> > Thanks Joerg,
> >
> > Artur...
> >
> >
> > -
> > Please check that your question  has not already been answered in the
> > FAQ before posting. 
> >
> > To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> > For additional commands, e-mail:   <[EMAIL PROTECTED]>
> >
> >
>
>
> -
> Please check that your question  has not already been answered in the
> FAQ before posting. 
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail:   <[EMAIL PROTECTED]>
>
>
>


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: Redirect in XSP

[Neil A]

Thanks Joerg and Artur, but in my case I'm building for WAP.  
Unfortunately the WML equivalent of your client side redirect crashes 
early Nokia 7110 phones.

I really want to use  but my URL is in the XML of the 
pipeline and I can't get it into a sitemap parameter:


	
	
		
	
	

	

	


Actions can't seem to read or transform the pipeline xml, they can only 
read and act on request parameters.  XSLT transformers can't create 
sitemap parameters.  So I'm a bit stuck.  Can anyone fill in the gap?

Thanks,

Neil.


On Saturday, November 9, 2002, at 03:23 AM, Artur Bialecki wrote:



Who should close the  element? The transformer can not send an
endElement() until everything inside is processed. Of course you have

to

Ofcourse, I don't know what I was thinking.


Does this make it a bit clearer? Everybody can of course improve my


This makes it very clear.

Thanks Joerg,

Artur...


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>





-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: URL Theory & Best Practices

[Kjetil Kjernsmo]

Hi!

Interesting thread! Most things has been said allready, but I'll just 
add a little .02 (whatever currency) :-)

On Thursday 07 November 2002 23:57, Tony Collen wrote:

> However, later I realize that using file extensions is "bad".  Read
> http://www.alistapart.com/stories/slashforward/ for more info on this
> idea.

The article is interesting, but a little too narrow. Indeed, using file 
extensions are Bad[tm] for URIs because you tie the address to a 
specific technology, which you may not be using in some years. For that 
reason not changing the default "cocoon" in Cocoon URIs are also a 
Bad Thing[tm].

The authorative reference on this topic is TimBL's rant "Cool URIs don't 
change": http://www.w3.org/Provider/Style/URI :-)

So, using directories for everything is one possibility, and if you do, 
make sure to include the trailing /, to avoid useless 301 redirects. 
Another option is to use Content Negotation, which is well defined in 
HTTP 1.1 (and earlier, IIRC), it's weird that it isn't more widely 
used. 

But, both content negotation and using directories for everything are 
both solutions that exists mainly because URIs have been so strongly 
tied to the file system of the server, and the mentioned article seems 
to take as granted that this connection is a necessity, but as Cocoon 
proves, this is not so. Just use sensible matches. It also means that 
requiring a trailing slash on every URI is a bit too much, I only do 
that if there is logically a hierarchal substructure. 

As for the problem of serving different formats to the client, I really 
have no good solution. What the user agents should do, was to let the 
user easily manipulate the Accept-header, so if the user wants a 
PDF-file, he would send only application/pdf in the Accept header, and 
the server would know that the user wanted a PDF-file, and send that. 
Given that it doesn't exist, appending the type to the URI is probably 
not too bad. 

Best,

Kjetil
-- 
Kjetil Kjernsmo
Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer
[EMAIL PROTECTED]  [EMAIL PROTECTED]  [EMAIL PROTECTED]
Homepage: http://www.kjetil.kjernsmo.net/


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>