Re: Swazoo Active Page Resource
Locked
 
|
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. |
RE: Swazoo Active Page Resource
|
|
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
|
RE: Swazoo Active Page Resource
|
|
In reply to this post by Ken Treis-4
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
|
|
|
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] |
«
Return to Swazoo
|
1 view|%1 views
| Free forum by Nabble | Edit this page |