Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Mime-Version: 1.0 (Apple Message framework v604)
In-Reply-To: <3FBEC23E.5020708@virbus.de>
References: <3FB97CAB.5080401@apache.org> <3FBA1E5C.1090802@vafer.org>
 <3FBA2554.8060507@virbus.de>
 <B4245574-1A70-11D8-AFDB-000393DA6672@sergeant.org>
 <3FBEC23E.5020708@virbus.de>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <9C46DCFC-1D04-11D8-ABC3-000393DA6672@sergeant.org>
Content-Transfer-Encoding: 7bit
From: Matt Sergeant <matt@sergeant.org>
Subject: Re: XSP "official" position
Date: Sat, 22 Nov 2003 15:57:44 +0000
To: dev@cocoon.apache.org

On 22 Nov 2003, at 1:56, Joerg Heinicke wrote:

>> This level of change to XSP should be discussed on 
>> xsp-dev@xml.apache.org, fwiw. I personally would be against this kind 
>> of logic control in XSP. Especially since it's perfectly possible to 
>> add this in as a tag library.
>
> I thought this list was dead and removed? Is there any archive 
> available about recent discussions? But I understand your concern as 
> Cocoon is not the only XSP implementing project.

I think the list is still alive.

> But I don't understand your concern related to this logic control.

What I mean is that I'm worried about turning XSP into a full blown 
programming language. It is XML after all - it's the worst possible 
syntax for programming in.

>>> Yes, afterwards it's very similar to XSLT or other template 
>>> languages as JXTemplate.
>>>
>>> The power of XSP is not XSP itself, but the further abstraction 
>>> levels as esql as Leszek pointed out. This would make an XML only 
>>> XSP to a really powerful template language in contrary to a 
>>> programming language with nasty syntax at the moment.
>> This isn't XSP's fault that it gets (ab)used this way. It's perfectly 
>> possible *today* to write XSPs that have no programming code in them.
>
> Might be, but the easier the abuse is, the more it will be abused.

I'm not sure what's more abusive though, conditions in XML with 
multiple namespaces or mixing a bit of Java or Perl in to do conditions 
(and/or loops). I'm not sold either way, fwiw. I'm just not too keen on 
being forced to use XML as a programming language (you are talking 
about forcing XSPs to be all XML, right?)

>> If Cocoon makes that hard I would consider it a bug (or at minimum a 
>> required feature for making XSP a reasonable framework to work with). 
>> Certainly it's very easy in AxKit - you just create a class and tell 
>> AxKit what methods are tags (sort of like SiLLy, but easier).
>
> Do you have an example? The XP guide is really short.

Sure. Here's a taglib for getting a cookie:

--BEGIN--
package ExampleCookieTaglib; use base 
Apache::AxKit::Language::XSP::TaglibHelper;

@EXPORT_TAGLIB = ('get_cookie($name)');
$NS = 'http://example.com/get-cookie';

sub get_cookie {
	my $name = shift;
	return Apache::Cookie->fetch->{$name}->value;
}

1;
--END--

(Note this is re-usable outside of XSP pages, which is a very useful 
feature for unit testing!)

Now that's callable via:

<cookie:get-cookie name="foo" 
xmlns:cookie="http://example.com/get-cookie"/>

or:

<cookie:get-cookie>
   <name><xsp:expr>$variable</xsp:expr></name>
</cookie:get-cookie>

or a multitude of other ways (also note that AxKit handled the 
translation of get_cookie to get-cookie transparently).

You can output tags of any shape or form using TaglibHelper. This 
example just output some character data.

Hope that helps.

Matt.