New modules on aolserver.am.net; also we are looking to hire a full-time AOLserver progr

Alex Hisen wrote:
> We've just finished a complete overhaul of http://
> <http://aolserver.am.net/
> aolserver.am.net/ and our entire company web
> site.  A much better look, better navigation and better
organization of
> content.  We've also taken the opportunity to release
some new C and Tcl
> modules:
> 
> *	ADP Master Pages Tcl Module
> <http://aolserver.am.net/code/modules/masterpages.adpx&g
t;  - implements
> ASP.NET 2.0-style Master Pages under AOLserver 4.0

Thanks for sharing this with the community.  It's been
somewhat 
depressing to see every php system include a simple
templating system 
but nothing really solid under AOLserver.  (I know OpenACS
has a 
templating system but I didn't look at it long enough to
grok all the 
complexity therin, not to mention that it is tightly tied to
OpenACS.)

One thought I had while looking at it is that it isn't
really suitable 
for letting untrusted users upload arbitrary master pages
for 
layout/styling/etc, as the users could then run scripts in 
the pages. 
I thought to myself, wouldn't a controlled environment for
ADPs be nice? 
  So I started looking at what it would take to add in a
safe adp 
execution mode, and I was happy to find that although it's
not 
documented, it already exists!

So a suggestion: it would be a nice enhancement to allow for
untrusted 
master pages that are run in safe mode.  I'm not entirely
sure what 
behavior makes the most sense (i.e., what can and can not be
in safe 
mode) but the implementation should be pretty simple 

-J


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to
<listservlistserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message.
You can leave the Subject: field of your email blank.

Jeff,

I developed a templating system which is safe for untrusted
users. 
Actually that was one of the main goals. The sources,
somewhat messy are at:

http://rmadilo.com/m2/servers/rmadilo/module
s/tcl/twt/packages/view/

The templates are 'compiled' into a Tcl script. 
The template compiler is a C program using flex/bison.

Here is a simple example of a template:

<table border="1">
[foreach num $MoveCards /]
<tr>
 [set k 0]
 [set Cards $CardList($num) /]
 [foreach Card $Cards /]
  <th>$Card<br />
  [if {$num == $MoveCount} /]
   [if {$k > 0} /]
 Move: 1<input type="radio"
name="move" value="$k [expr ($k - 1)
/]">
   [/if/]
   [if {$k > 2} /]
  3<input type="radio" name="move"
value="$k [expr ($k - 3) /]">
   [/if/]
  [/if/]
 </th>
 [incr k /]
 [/foreach/]
</tr>
[/foreach/]
</table>

This is taken from an start.tmpl under:
http://rmadilo.com/m2/servers/rmadilo/pages/optimistic/

The live version, to see the resulting html is here:
http://rmadilo.com/opt
imistic/

If there is a syntax error in the script, you get a compile
time error, 
it is pretty easy to track down the error by trying to
compile it on the 
command line. The compiler aborts at the error. 

The compiler itself has only a limited number of commands,
each with a form 
similar to a tcl command:

[command args ] ... ?[/command]?

Anything not in [ ] is turned into text. Parsing is not yet
100% perfect and
 sometimes messes up if there are some combination of "
and {. 

Any variables found in the text, outside of [ ] are also
handled. The compiled script,
although ugly is just a series of commands which eventually
boil down to a series of
[append]s, but they are also easy to debug if some problem
shows up. 

The safety comes from only supporting a limited set of safe
commands and variable
forms. For instance, you can't have an array variable like
$a([rm -rf /]). Also, the
for and while loop are not available because they execute
code. 

The main extension mechanism is the [resource] tag. Before a
template is run, you can add
resources, giving them a name. If the resource is in the
template, it is executed, possibly
passing through arguments. For instance, you could give the
template the ability to open
a particular file. It would be nice to have another tag
which could do something to the
contents of the tag (the stuff between [tag] [/tag]), but I
haven't given this any thought
yet.

This is hardly a perfect system, but the main goal of
establishing a safe exection environment 
seems to be met.  

The way I use this is to have a .tcl file setup all the data
and then use ::view::return to 
find and handle the similarly named .tmpl file. However, the
data could be setup from some other
source, in a filter or registered proc, or the template
itself could be anywhere, like a database
or outside of pageroot, or passed in via a form. 

tom jackson

On Monday 24 September 2007 12:54, Jeff Rogers wrote:
> Thanks for sharing this with the community.  It's been
somewhat
> depressing to see every php system include a simple
templating system
> but nothing really solid under AOLserver.  (I know
OpenACS has a
> templating system but I didn't look at it long enough
to grok all the
> complexity therin, not to mention that it is tightly
tied to OpenACS.)
>
> One thought I had while looking at it is that it isn't
really suitable
> for letting untrusted users upload arbitrary master
pages for
> layout/styling/etc, as the users could then run scripts
in  the pages.
> I thought to myself, wouldn't a controlled environment
for ADPs be nice?
>   So I started looking at what it would take to add in
a safe adp
> execution mode, and I was happy to find that although
it's not
> documented, it already exists!
>
> So a suggestion: it would be a nice enhancement to
allow for untrusted
> master pages that are run in safe mode.  I'm not
entirely sure what
> behavior makes the most sense (i.e., what can and can
not be in safe
> mode) but the implementation should be pretty simple



--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to
<listservlistserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message.
You can leave the Subject: field of your email blank.

This reminds me of the Smarty for PHP.  Has anyone looked at
porting  
Smarty to ADP?  It's pretty PHP-specific but the syntax,
like Tom's  
stuff below, is pretty convenient.

http://smarty.php.net/

-Jim





On Sep 25, 2007, at 10:50 AM, Tom Jackson wrote:

> Jeff,
>
> I developed a templating system which is safe for
untrusted users.
> Actually that was one of the main goals. The sources,
somewhat  
> messy are at:
>
> http://rmadilo.com/m2/servers/rmadilo/module
s/tcl/twt/packages/view/
>
> The templates are 'compiled' into a Tcl script.
> The template compiler is a C program using flex/bison.
>
> Here is a simple example of a template:
>
> <table border="1">
> [foreach num $MoveCards /]
> <tr>
>  [set k 0]
>  [set Cards $CardList($num) /]
>  [foreach Card $Cards /]
>   <th>$Card<br />
>   [if {$num == $MoveCount} /]
>    [if {$k > 0} /]
>  Move: 1<input type="radio"
name="move" value="$k [expr ($k - 1)
/]">
>    [/if/]
>    [if {$k > 2} /]
>   3<input type="radio"
name="move" value="$k [expr ($k - 3)
/]">
>    [/if/]
>   [/if/]
>  </th>
>  [incr k /]
>  [/foreach/]
> </tr>
> [/foreach/]
> </table>
>
> This is taken from an start.tmpl under:
> http://rmadilo.com/m2/servers/rmadilo/pages/optimistic/
>
> The live version, to see the resulting html is here:
> http://rmadilo.com/opt
imistic/
>
> If there is a syntax error in the script, you get a
compile time  
> error,
> it is pretty easy to track down the error by trying to
compile it  
> on the
> command line. The compiler aborts at the error.
>
> The compiler itself has only a limited number of
commands, each  
> with a form
> similar to a tcl command:
>
> [command args ] ... ?[/command]?
>
> Anything not in [ ] is turned into text. Parsing is not
yet 100%  
> perfect and
>  sometimes messes up if there are some combination of
" and {.
>
> Any variables found in the text, outside of [ ] are
also handled.  
> The compiled script,
> although ugly is just a series of commands which
eventually boil  
> down to a series of
> [append]s, but they are also easy to debug if some
problem shows up.
>
> The safety comes from only supporting a limited set of
safe  
> commands and variable
> forms. For instance, you can't have an array variable
like $a([rm - 
> rf /]). Also, the
> for and while loop are not available because they
execute code.
>
> The main extension mechanism is the [resource] tag.
Before a  
> template is run, you can add
> resources, giving them a name. If the resource is in
the template,  
> it is executed, possibly
> passing through arguments. For instance, you could give
the  
> template the ability to open
> a particular file. It would be nice to have another tag
which could  
> do something to the
> contents of the tag (the stuff between [tag] [/tag]),
but I haven't  
> given this any thought
> yet.
>
> This is hardly a perfect system, but the main goal of
establishing  
> a safe exection environment
> seems to be met.
>
> The way I use this is to have a .tcl file setup all the
data and  
> then use ::view::return to
> find and handle the similarly named .tmpl file.
However, the data  
> could be setup from some other
> source, in a filter or registered proc, or the template
itself  
> could be anywhere, like a database
> or outside of pageroot, or passed in via a form.
>
> tom jackson
>
> On Monday 24 September 2007 12:54, Jeff Rogers wrote:
>> Thanks for sharing this with the community.  It's
been somewhat
>> depressing to see every php system include a simple
templating system
>> but nothing really solid under AOLserver.  (I know
OpenACS has a
>> templating system but I didn't look at it long
enough to grok all the
>> complexity therin, not to mention that it is
tightly tied to  
>> OpenACS.)
>>
>> One thought I had while looking at it is that it
isn't really  
>> suitable
>> for letting untrusted users upload arbitrary master
pages for
>> layout/styling/etc, as the users could then run
scripts in  the  
>> pages.
>> I thought to myself, wouldn't a controlled
environment for ADPs be  
>> nice?
>>   So I started looking at what it would take to add
in a safe adp
>> execution mode, and I was happy to find that
although it's not
>> documented, it already exists!
>>
>> So a suggestion: it would be a nice enhancement to
allow for  
>> untrusted
>> master pages that are run in safe mode.  I'm not
entirely sure what
>> behavior makes the most sense (i.e., what can and
can not be in safe
>> mode) but the implementation should be pretty
simple 
>
>
> --
> AOLserver - http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email
to  
> <listservlistserv.aol.com> with the
> body of "SIGNOFF AOLSERVER" in the email
message. You can leave the  
> Subject: field of your email blank.


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to
<listservlistserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message.
You can leave the Subject: field of your email blank.

On 2007.09.27, Jim Davidson <jgdavidsonMAC.COM> wrote:
> This reminds me of the Smarty for PHP.  Has anyone
looked at porting  
> Smarty to ADP?  It's pretty PHP-specific but the
syntax, like Tom's  
> stuff below, is pretty convenient.
> 
> http://smarty.php.net/

Wow, Jim--I'm surprised to hear that you like Smarty.  

It should be possible to write a Smarty template parser to
use instead
of the ADP parser.  Smarty's tight coupling to PHP makes
this a bad
idea, though--i.e., without the ability to evaluate PHP code
in a Smarty
template, most PHP pages that use Smarty won't work
"out of the box" in
a Smarty template parser for AOLserver.

Still, if someone wanted to take on this kind of work, I'd
love to see
it demonstrated.

-- Dossy

-- 
Dossy Shiobara              | dossypanoptic.com | http://dossy.org/
Panoptic Computer Network   | http://panoptic.com/
  "He realized the fastest way to change is to laugh at
your own
    folly -- then you can let go and quickly move on."
(p. 70)


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to
<listservlistserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message.
You can leave the Subject: field of your email blank.

Wow that is pretty interesting, lots of good ideas. 

In my example below, there are places where you see a tag
like [/if/],

the ending /] means that following whitespace should be
removed completely. It 
looks like smarty has a tag  which is essentially an
html type 
normalization. All whitespace is condensed to a single
whitespace. 

I added my whitespace remover so that the template code
could produce whatever 
output was intended, so if several template tags appear next
to each other, 
you can place them on separate lines, or whatever. 

Looking at this, makes me think I should add a [space] tag,
or [wspace {...}] 
type tag. 

One of the basic ideas of smarty is to separate data
creation from 
presentation, something I was hoping to achieve. 

One relatively big difference between my templating system
and smarty is that 
templating/compiling are independent of the Tcl environment.
You could use it 
in a regular tcl script. Caching, etc. are not built in, but
can be easily 
added in any number of ways (including http caching).

Using the concept of a named resource, you can include a
header using this:

[resource header]

Assuming that prior to running the template, you did
something like this:
::resource::add header resource::include $header_file_name

So, ::resource::add is similar to assign, but it adds procs
with/without args. 

Note, that resource::include is not executed until the
template is executed.

tom jackson

On Thursday 27 September 2007 14:51, Jim Davidson wrote:
> This reminds me of the Smarty for PHP.  Has anyone
looked at porting
> Smarty to ADP?  It's pretty PHP-specific but the
syntax, like Tom's
> stuff below, is pretty convenient.
>
> http://smarty.php.net/
>
> -Jim
>
> On Sep 25, 2007, at 10:50 AM, Tom Jackson wrote:
> > Jeff,
> >
> > I developed a templating system which is safe for
untrusted users.
> > Actually that was one of the main goals. The
sources, somewhat
> > messy are at:
> >
> > http://rmadilo.com/m2/servers/rmadilo/module
s/tcl/twt/packages/view/
> >
> > The templates are 'compiled' into a Tcl script.
> > The template compiler is a C program using
flex/bison.
> >
> > Here is a simple example of a template:
> >
> > <table border="1">
> > [foreach num $MoveCards /]
> > <tr>
> >  [set k 0]
> >  [set Cards $CardList($num) /]
> >  [foreach Card $Cards /]
> >   <th>$Card<br />
> >   [if {$num == $MoveCount} /]
> >    [if {$k > 0} /]
> >  Move: 1<input type="radio"
name="move" value="$k [expr ($k - 1)
/]">
> >    [/if/]
> >    [if {$k > 2} /]
> >   3<input type="radio"
name="move" value="$k [expr ($k - 3)
/]">
> >    [/if/]
> >   [/if/]
> >  </th>
> >  [incr k /]
> >  [/foreach/]
> > </tr>
> > [/foreach/]
> > </table>
> >
> > This is taken from an start.tmpl under:
> > http://rmadilo.com/m2/servers/rmadilo/pages/optimistic/
> >
> > The live version, to see the resulting html is
here:
> > http://rmadilo.com/opt
imistic/
> >
> > If there is a syntax error in the script, you get
a compile time
> > error,
> > it is pretty easy to track down the error by
trying to compile it
> > on the
> > command line. The compiler aborts at the error.
> >
> > The compiler itself has only a limited number of
commands, each
> > with a form
> > similar to a tcl command:
> >
> > [command args ] ... ?[/command]?
> >
> > Anything not in [ ] is turned into text. Parsing
is not yet 100%
> > perfect and
> >  sometimes messes up if there are some combination
of " and {.
> >
> > Any variables found in the text, outside of [ ]
are also handled.
> > The compiled script,
> > although ugly is just a series of commands which
eventually boil
> > down to a series of
> > [append]s, but they are also easy to debug if some
problem shows up.
> >
> > The safety comes from only supporting a limited
set of safe
> > commands and variable
> > forms. For instance, you can't have an array
variable like $a([rm -
> > rf /]). Also, the
> > for and while loop are not available because they
execute code.
> >
> > The main extension mechanism is the [resource]
tag. Before a
> > template is run, you can add
> > resources, giving them a name. If the resource is
in the template,
> > it is executed, possibly
> > passing through arguments. For instance, you could
give the
> > template the ability to open
> > a particular file. It would be nice to have
another tag which could
> > do something to the
> > contents of the tag (the stuff between [tag]
[/tag]), but I haven't
> > given this any thought
> > yet.
> >
> > This is hardly a perfect system, but the main goal
of establishing
> > a safe exection environment
> > seems to be met.
> >
> > The way I use this is to have a .tcl file setup
all the data and
> > then use ::view::return to
> > find and handle the similarly named .tmpl file.
However, the data
> > could be setup from some other
> > source, in a filter or registered proc, or the
template itself
> > could be anywhere, like a database
> > or outside of pageroot, or passed in via a form.
> >
> > tom jackson
> >
> > On Monday 24 September 2007 12:54, Jeff Rogers
wrote:
> >> Thanks for sharing this with the community. 
It's been somewhat
> >> depressing to see every php system include a
simple templating system
> >> but nothing really solid under AOLserver.  (I
know OpenACS has a
> >> templating system but I didn't look at it long
enough to grok all the
> >> complexity therin, not to mention that it is
tightly tied to
> >> OpenACS.)
> >>
> >> One thought I had while looking at it is that
it isn't really
> >> suitable
> >> for letting untrusted users upload arbitrary
master pages for
> >> layout/styling/etc, as the users could then
run scripts in  the
> >> pages.
> >> I thought to myself, wouldn't a controlled
environment for ADPs be
> >> nice?
> >>   So I started looking at what it would take
to add in a safe adp
> >> execution mode, and I was happy to find that
although it's not
> >> documented, it already exists!
> >>
> >> So a suggestion: it would be a nice
enhancement to allow for
> >> untrusted
> >> master pages that are run in safe mode.  I'm
not entirely sure what
> >> behavior makes the most sense (i.e., what can
and can not be in safe
> >> mode) but the implementation should be pretty
simple 
> >
> > --
> > AOLserver - http://www.aolserver.com/
> >
> > To Remove yourself from this list, simply send an
email to
> > <listservlistserv.aol.com> with the
> > body of "SIGNOFF AOLSERVER" in the email
message. You can leave the
> > Subject: field of your email blank.
>
> --
> AOLserver - http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email
to
> <listservlistserv.aol.com> with the body of
"SIGNOFF AOLSERVER" in the
> email message. You can leave the Subject: field of your
email blank.


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to
<listservlistserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message.
You can leave the Subject: field of your email blank.