From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,469b2bba5f3a7bd
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII
Received: by 10.68.202.168 with SMTP id kj8mr1956662pbc.1.1334326292026;
        Fri, 13 Apr 2012 07:11:32 -0700 (PDT)
Path: 
 r9ni51768pbh.0!nntp.google.com!news1.google.com!goblin3!goblin.stu.neva.ru!bolzen.all.de!fu-berlin.de!dotsrc.org!filter.dotsrc.org!news.dotsrc.org!not-for-mail
Date: Fri, 13 Apr 2012 16:11:29 +0200
From: =?ISO-8859-1?Q?Thomas_L=F8cke?= <thomas@12boo.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:11.0) Gecko/20120403 Thunderbird/11.0.1
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: New AWS-based website
References: 
 <76df311e-7bac-4326-bf21-b611c701ebeb@do4g2000vbb.googlegroups.com>
 <4f868816$0$282$14726298@news.sunsite.dk>
 <6ea96041-f949-421b-a76e-05ada890ec77@z17g2000yqf.googlegroups.com>
 <4f86e680$0$294$14726298@news.sunsite.dk>
 <27649df6-34b0-4bf5-8d9d-20b86d260639@v22g2000vby.googlegroups.com>
In-Reply-To: 
 <27649df6-34b0-4bf5-8d9d-20b86d260639@v22g2000vby.googlegroups.com>
Message-ID: <4f883411$0$281$14726298@news.sunsite.dk>
Organization: SunSITE.dk - Supporting Open source
NNTP-Posting-Host: 77.234.168.91
X-Trace: news.sunsite.dk
 DXC=j3]8R0QDmUFK0]X@\@M^fKYSB=nbEKnkKcc:lZ@]ReCD3ZOKe3?:>XAcAE?;m5ccYC3>^Oo7SF<fE4oeR>?=Q06O
X-Complaints-To: staff@sunsite.dk
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Date: 2012-04-13T16:11:29+02:00
List-Id: <comp.lang.ada>

On 04/13/2012 09:35 AM, Maciej Sobczak wrote:
> That's why I see no place for template parsers built into AWS - in
> other words, between generating HTML directly and generating XML (that
> is transformed by XSLT on the client side) there is no space left and
> therefore server-side template parser is a solution to the problem
> that does not exist.



Client side XSLT transformations is not a trivial matter, especially not
if you're targetting browsers. It's more or less impossible to write XSL
that will work the same across a great many browsers (and versions), and
you cannot be sure that XSLT is even properly supported by all browsers.

So more often than not, you will have to do the transformation on the
server, in which case templates_parser might do the job just as well,
while also being a lot faster. Most XSLT processors are heavy beasts.

 From my meager tests templates_parser is very fast, so there might just
be a few situations where it could come in handy.



> I think it does not need to be. Doing it properly (that is, flexibly
> enough to cover all needs) would be a huge amount of work and it would
> always be a wrong solution for some purpose. Considering that doing it
> right in the actual context of the target system is not difficult at
> all (support for cookies is all that is neededd), there is again no
> problem to solve with the library-based solution.
>
> In other words - if the session management can be done entirely in
> memory, then a screenful of code does the job and the library has
> little added value; and if it requires support from the database, then
> the general-purpose library feature will not be adequate anyway.



You're probably right. I guess I'm just too used to thinking about
sessions and cookies in the context of PHP. Old (and bad) habits are
hard to kill.

Maybe the AWS.Session package could be made a bit more useful if we
could register our own create/destroy/read/write procedures?


-- 
Thomas L�cke | thomas@12boo.net | http://12boo.net