Re: Swazoo Active Page Resource

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Swazoo Active Page Resource

Ken Treis-4
(CC'd to the list)

Jeff,

The SwazooActivePage stuff is experimental code, but I like the general direction that it leads: It's a lot easier to write HTML in an HTML editor than in a Smalltalk method with #nextPutAll.  And in general, most of these pages contain mostly HTML with just a little ST logic.

I have started building some sites using SAPs, and I've found that they work pretty well.  I've also been playing with a sort of Swazoo "content source model" that helps to minimize the amount of actual ST code that ends up in the SAP.  I've observed -- surprise, surprise -- that ST code in a flat file is less maintainable than ST code in an image.  So, with some sort of content source and content model, your SAP code gets thinner; it becomes like a simple view.

But SAPs also need some work.

- They need a more intelligent error reporting mechanism, more like PHP ("line 56: messageNotUnderstood: #self").
- They need to add parentheses around the embedded code components.
- Some shortcuts for accessing HTTP Post data and URI queries would be helpful.
- They need to trap parse errors.  Without an interactive parser, I make all sorts of mistakes with parentheses.  :-P
- They don't run in any sort of sandbox.  A SAP can say <? ObjectMemory quit ?> and bring a VW image to its knees. This isn't a concern for me yet -- I don't give any of my customers access to SAP capabilities yet -- but it is probably something that we should keep in mind.

These are just the ideas that come to mind at present.

I haven't used Seaside or VW's new Web Toolkit, but I've used PHP a little.  So perhaps it's not surprising that SAPs are PHP-like.  There are some people who would like to see Swazoo become more like Zope, and others who would like it to become more like Seaside, and others who want to port the AIDA application framework.  I'm glad that there's so much interest; I'm also glad that Swazoo's resource-oriented architecture will allow for all of those things to happen.

There's no reason that Swazoo can't support several different active page frameworks, or several different ways of building web apps.  Then, when it comes time to build a site, you have your choice of technologies, all within the same environment.

I'd be interested in collaborating on SAP improvements, so please describe what your active page port was/is capable of. It'd be a good start for discussion.

--
Ken Treis
[hidden email]

Steve Waring wrote:
Hi Jeff,

SwazooActivePages is by Ken Tries. A couple of months ago we swapped some
code and ideas back and forth, but I didnt keep working on it. The Dolphin
version at least has only been used in test cases.

  
In my D4 prototype of a Swazoo App, I had partially ported at Smalltalk
Server Page app from another project.  I noticed in the latest Swazoo
Active Page Resource and experimental class SwazooActivePageResource.
I'd rather collaborate than go in my own direction... so I started
fooling around.
    

Is Smalltalk Server Page a specification or is it defined by VW's
implementation of it?

  
I played around a bit, but found first that I never got by the method
URIResolution>>resolveLeafResource: aResource.  The test "self atEnd"
would never be true - there is always a file name hanging out there in
the URI:

resolveLeafResource: aResource
(aResource canAnswer
and: [self atEnd
and: [self stringMatch: aResource]]) ifFalse: [^nil].
^self getAnswerFrom: aResource
    

Thanks! that is the problem. I will pullup FileResource>>helpResolve: to
FileMappingResource.

  
Once I worked around that, I found I had compilation problems on the
page I'm still looking at.
    

It is not debugger friendly.

  
It looks like from the test cases you are working from some
specification - ASP perhaps?
    

No, just muck around. The idea behind it was that "<#" introduces an "active
tag"

 - "<?"
 - "<$"  $ for String
 - "<%" % for Print
 - "<|   for a collection that will be enumerated

The first pass takes a string like: '<HTML><% 123 + 456 %></HTML>' and
outputs (stream accessing) code.
The second pass evaluates this code in a context to output html.

  
Can we discuss a bit where you are
heading, and maybe we can work together on this if it makes sense.
    

At the moment it is heading nowhere so it would be good to give it a push
along. Seaside was released at about the same time we were playing with
this, and my preference would be to port Seaside. I think its two template
systems could be used independently of the page building/continuation code.

What have you done so far?
What do you need from templates?

Steve
[hidden email]
http://www.dolphinharbor.org


  
jlo



Jeffrey Odell
Email: [hidden email]
Phone: 813.335.6966

http://www.odellsoft.com <http://www.odellsoft.com/>


    


  


Reply | Threaded
Open this post in threaded view
|

RE: Swazoo Active Page Resource

Jeffrey Odell
Message
Mine was a somewhat more simplistic framework - for example, I didn't turn the page into one large compiled method.  I cached the straight HTML text, and only compiled the tags.  This was sufficient for the application I was working on, but doesn't support some of the functions of and .ASP or .JSP page.  Also, it had the "Smalltalk halt" glaring problem.
 
My goal is to externalize the HTML somehow.  Using .ASP or .JSP compatible tabs is a nice trick to get editors to leave them alone.
 
Rouge scripts in the file are definitely a problem.  One idea I heard in a scripting tool from Totally Objects is to require a digital signature of some kind (they used MD5?) with the script. Any alteration of the script can then be rejected by Smalltalk.
 
Error reporting was not a problem with my framework, as I didn't create a giant compiled method.  I'm pretty sure the trick is to have a tested model doing all the real wok, and have the embedded HTML do as little as possible.
 
I'm very interested in getting Seaside to Dolphin, as I find Session Management to be the most annoying problem when doing these web applications, and it has such an interesting abstraction.  Perhaps it is time to bug Andy/Blair about continuations again.  Integrating that with Swazoo, and having externalized pages, seems to be an interesting combination.
 
I'm still getting my arms around the latest Swazoo, but I'll keep looking at this - perhaps it is time to move forward an open source, portable server page framework.
 
Thanks for the info -
 
jlo
-----Original Message-----
From: Ken Treis [mailto:[hidden email]]
Sent: Saturday, May 18, 2002 2:22 PM
To: Steve Waring
Cc: Jeffrey Odell; [hidden email]
Subject: Re: Swazoo Active Page Resource

(CC'd to the list)

Jeff,

The SwazooActivePage stuff is experimental code, but I like the general direction that it leads: It's a lot easier to write HTML in an HTML editor than in a Smalltalk method with #nextPutAll.  And in general, most of these pages contain mostly HTML with just a little ST logic.

I have started building some sites using SAPs, and I've found that they work pretty well.  I've also been playing with a sort of Swazoo "content source model" that helps to minimize the amount of actual ST code that ends up in the SAP.  I've observed -- surprise, surprise -- that ST code in a flat file is less maintainable than ST code in an image.  So, with some sort of content source and content model, your SAP code gets thinner; it becomes like a simple view.

But SAPs also need some work.

- They need a more intelligent error reporting mechanism, more like PHP ("line 56: messageNotUnderstood: #self").
- They need to add parentheses around the embedded code components.
- Some shortcuts for accessing HTTP Post data and URI queries would be helpful.
- They need to trap parse errors.  Without an interactive parser, I make all sorts of mistakes with parentheses.  :-P
- They don't run in any sort of sandbox.  A SAP can say <? ObjectMemory quit ?> and bring a VW image to its knees. This isn't a concern for me yet -- I don't give any of my customers access to SAP capabilities yet -- but it is probably something that we should keep in mind.

These are just the ideas that come to mind at present.

I haven't used Seaside or VW's new Web Toolkit, but I've used PHP a little.  So perhaps it's not surprising that SAPs are PHP-like.  There are some people who would like to see Swazoo become more like Zope, and others who would like it to become more like Seaside, and others who want to port the AIDA application framework.  I'm glad that there's so much interest; I'm also glad that Swazoo's resource-oriented architecture will allow for all of those things to happen.

There's no reason that Swazoo can't support several different active page frameworks, or several different ways of building web apps.  Then, when it comes time to build a site, you have your choice of technologies, all within the same environment.

I'd be interested in collaborating on SAP improvements, so please describe what your active page port was/is capable of. It'd be a good start for discussion.

--
Ken Treis
[hidden email]

Steve Waring wrote:
Hi Jeff,

SwazooActivePages is by Ken Tries. A couple of months ago we swapped some
code and ideas back and forth, but I didnt keep working on it. The Dolphin
version at least has only been used in test cases.

  
In my D4 prototype of a Swazoo App, I had partially ported at Smalltalk
Server Page app from another project.  I noticed in the latest Swazoo
Active Page Resource and experimental class SwazooActivePageResource.
I'd rather collaborate than go in my own direction... so I started
fooling around.
    

Is Smalltalk Server Page a specification or is it defined by VW's
implementation of it?

  
I played around a bit, but found first that I never got by the method
URIResolution>>resolveLeafResource: aResource.  The test "self atEnd"
would never be true - there is always a file name hanging out there in
the URI:

resolveLeafResource: aResource
(aResource canAnswer
and: [self atEnd
and: [self stringMatch: aResource]]) ifFalse: [^nil].
^self getAnswerFrom: aResource
    

Thanks! that is the problem. I will pullup FileResource>>helpResolve: to
FileMappingResource.

  
Once I worked around that, I found I had compilation problems on the
page I'm still looking at.
    

It is not debugger friendly.

  
It looks like from the test cases you are working from some
specification - ASP perhaps?
    

No, just muck around. The idea behind it was that "<#" introduces an "active
tag"

 - "<?"
 - "<$"  $ for String
 - "<%" % for Print
 - "<|   for a collection that will be enumerated

The first pass takes a string like: '<HTML><% 123 + 456 %></HTML>' and
outputs (stream accessing) code.
The second pass evaluates this code in a context to output html.

  
Can we discuss a bit where you are
heading, and maybe we can work together on this if it makes sense.
    

At the moment it is heading nowhere so it would be good to give it a push
along. Seaside was released at about the same time we were playing with
this, and my preference would be to port Seaside. I think its two template
systems could be used independently of the page building/continuation code.

What have you done so far?
What do you need from templates?

Steve
[hidden email]
http://www.dolphinharbor.org


  
jlo



Jeffrey Odell
Email: [hidden email]
Phone: 813.335.6966

http://www.odellsoft.com <http://www.odellsoft.com/>


    


  


Reply | Threaded
Open this post in threaded view
|

RE: Swazoo Active Page Resource

Jeffrey Odell
In reply to this post by Ken Treis-4
Message
One thought as I looked through this - I think the method created from the page is executed in the context of an instance of SwazooActivePage - in other words, #self answer the instance of the page.  The server page frameworks like ASP and JSP have a set of well defined objects that can be reached - HTTP Request HTTP Response, session, etc. at know variable names.
 
It seems like an object that defines this context should be created and be the context of the method.  It would answer the basic objects the script uses: HTTP Request HTTP Response, User Session (a know session looked up from Swazoo Session and holding the session-specific data, and perhaps a Server object with some server specific stuff (These ideas stolen from ASP),
 
That way, in my script I can refer to "session", request, etc. and know they will be there.
 
Alternatively, In the current situation, I'd have to do: (self request environmentAt: #session) to grab the SwazooSession.
 
jlo
 
 
-----Original Message-----
From: Ken Treis [mailto:[hidden email]]
Sent: Saturday, May 18, 2002 2:22 PM
To: Steve Waring
Cc: Jeffrey Odell; [hidden email]
Subject: Re: Swazoo Active Page Resource

(CC'd to the list)

Jeff,

The SwazooActivePage stuff is experimental code, but I like the general direction that it leads: It's a lot easier to write HTML in an HTML editor than in a Smalltalk method with #nextPutAll.  And in general, most of these pages contain mostly HTML with just a little ST logic.

I have started building some sites using SAPs, and I've found that they work pretty well.  I've also been playing with a sort of Swazoo "content source model" that helps to minimize the amount of actual ST code that ends up in the SAP.  I've observed -- surprise, surprise -- that ST code in a flat file is less maintainable than ST code in an image.  So, with some sort of content source and content model, your SAP code gets thinner; it becomes like a simple view.

But SAPs also need some work.

- They need a more intelligent error reporting mechanism, more like PHP ("line 56: messageNotUnderstood: #self").
- They need to add parentheses around the embedded code components.
- Some shortcuts for accessing HTTP Post data and URI queries would be helpful.
- They need to trap parse errors.  Without an interactive parser, I make all sorts of mistakes with parentheses.  :-P
- They don't run in any sort of sandbox.  A SAP can say <? ObjectMemory quit ?> and bring a VW image to its knees. This isn't a concern for me yet -- I don't give any of my customers access to SAP capabilities yet -- but it is probably something that we should keep in mind.

These are just the ideas that come to mind at present.

I haven't used Seaside or VW's new Web Toolkit, but I've used PHP a little.  So perhaps it's not surprising that SAPs are PHP-like.  There are some people who would like to see Swazoo become more like Zope, and others who would like it to become more like Seaside, and others who want to port the AIDA application framework.  I'm glad that there's so much interest; I'm also glad that Swazoo's resource-oriented architecture will allow for all of those things to happen.

There's no reason that Swazoo can't support several different active page frameworks, or several different ways of building web apps.  Then, when it comes time to build a site, you have your choice of technologies, all within the same environment.

I'd be interested in collaborating on SAP improvements, so please describe what your active page port was/is capable of. It'd be a good start for discussion.

--
Ken Treis
[hidden email]

Steve Waring wrote:
Hi Jeff,

SwazooActivePages is by Ken Tries. A couple of months ago we swapped some
code and ideas back and forth, but I didnt keep working on it. The Dolphin
version at least has only been used in test cases.

  
In my D4 prototype of a Swazoo App, I had partially ported at Smalltalk
Server Page app from another project.  I noticed in the latest Swazoo
Active Page Resource and experimental class SwazooActivePageResource.
I'd rather collaborate than go in my own direction... so I started
fooling around.
    

Is Smalltalk Server Page a specification or is it defined by VW's
implementation of it?

  
I played around a bit, but found first that I never got by the method
URIResolution>>resolveLeafResource: aResource.  The test "self atEnd"
would never be true - there is always a file name hanging out there in
the URI:

resolveLeafResource: aResource
(aResource canAnswer
and: [self atEnd
and: [self stringMatch: aResource]]) ifFalse: [^nil].
^self getAnswerFrom: aResource
    

Thanks! that is the problem. I will pullup FileResource>>helpResolve: to
FileMappingResource.

  
Once I worked around that, I found I had compilation problems on the
page I'm still looking at.
    

It is not debugger friendly.

  
It looks like from the test cases you are working from some
specification - ASP perhaps?
    

No, just muck around. The idea behind it was that "<#" introduces an "active
tag"

 - "<?"
 - "<$"  $ for String
 - "<%" % for Print
 - "<|   for a collection that will be enumerated

The first pass takes a string like: '<HTML><% 123 + 456 %></HTML>' and
outputs (stream accessing) code.
The second pass evaluates this code in a context to output html.

  
Can we discuss a bit where you are
heading, and maybe we can work together on this if it makes sense.
    

At the moment it is heading nowhere so it would be good to give it a push
along. Seaside was released at about the same time we were playing with
this, and my preference would be to port Seaside. I think its two template
systems could be used independently of the page building/continuation code.

What have you done so far?
What do you need from templates?

Steve
[hidden email]
http://www.dolphinharbor.org


  
jlo



Jeffrey Odell
Email: [hidden email]
Phone: 813.335.6966

http://www.odellsoft.com <http://www.odellsoft.com/>


    


  


Reply | Threaded
Open this post in threaded view
|

Re: Swazoo Active Page Resource

Ken Treis-4
Jeffrey Odell wrote:
Message
One thought as I looked through this - I think the method created from the page is executed in the context of an instance of SwazooActivePage - in other words, #self answer the instance of the page.  The server page frameworks like ASP and JSP have a set of well defined objects that can be reached - HTTP Request HTTP Response, session, etc. at know variable names.
 
It seems like an object that defines this context should be created and be the context of the method.  It would answer the basic objects the script uses: HTTP Request HTTP Response, User Session (a know session looked up from Swazoo Session and holding the session-specific data, and perhaps a Server object with some server specific stuff (These ideas stolen from ASP),
 
That way, in my script I can refer to "session", request, etc. and know they will be there.
 
Alternatively, In the current situation, I'd have to do: (self request environmentAt: #session) to grab the SwazooSession.
Or, simply "request session".  The request was made an instance variable, so you can refer to it directly.  And there's a helper on HTTPRequest that gives you back the session.

This evaluation context was by design.  The thought was that ASP-like "helpers" could be added as methods on SwazooActivePage, so "self browser" would return the browser string from the request, "self peerIPString" could give you back the requestor's IP address, etc.

It didn't seem too hard to refer to the session with "request session", but if you wanted to refer to it directly, you could make a subclass of SwazooActivePage that overrides #request: like this:

request: aRequest
    super request: aRequest.
    session := aRequest session

(You may also have to create your own SwazooActivePageResource for this; it'd use your class instead of SAPage)

I didn't want to put the session as an instance variable for all SAPs, because not all requests have sessions.  And "request session" seemed direct enough.


--
Ken Treis
[hidden email]