In Seaside, is there a way to have an anchor tag that will submit a form and perform an action (behaving just like a button)?
Thank you, Derek
Nerd on a Wire: Web and Information Solutions Website Design - Database Systems - Site Hosting 604.874.6463 mailto:info@nerdonawire.com For more information, visit http://nerdonawire.com
On Fri, 7 Feb 2003, Derek Brans wrote:
In Seaside, is there a way to have an anchor tag that will submit a form and perform an action (behaving just like a button)?
You'd have to do two things, I think: - make the action the default action of the form (HtmlRenderer>>defaultAction:) - create a normal link (#anchorWithUrl:text:) that used JS to submit the form
As for what the javascript should be, I have no idea.
- create a normal link (#anchorWithUrl:text:) that used JS to submit
the form
As for what the javascript should be, I have no idea.
html anchorWithUrl: 'javascript:submit()' text: aString
Derek Brans wrote:
In Seaside, is there a way to have an anchor tag that will submit a form and perform an action (behaving just like a button)?
I've got a scheme that seems to work OK:
Suppose you've got a component 'Foo', with launch URL of 'http://localhost/seaside/foo' (or whatever machine and port you choose). Now, suppose the 'Foo' component has links 'red' and 'green' in the GUI, which you want to use to invoke methods #red and #green on component Foo when the links are clicked on.
1. Define the URL for the 'red' link to be '/seaside/foo/red', and for the 'green' link to be '/seaside/foo/green'.
2. Give 'Foo' an instance variable called 'targets', and then create an #initialize method of 'Foo' thus:
initialize targets _ OrderedCollection new. targets add: #red; add: #green
3. Give 'Foo' a 'lastTarget' instance variable, which will be used to prevent recursive circularities, as shown later.
4. Put the following in Foo's #renderContentOn:
renderContentOn: html | path sel | path _ self session path. sel _ (path copyAfterLast: $/) asLegalSelector asSymbol. (lastTarget ~= sel and: [targets includes: sel]) ifTrue: [lastTarget _ sel. ^self perform: sel]. { ... the rest of the normal rendering code here ... }
With the above, the 'red' and 'green' links will invoke the #red and #green target methods (respectively) of the component, just like a button does.
You can, if you wish, easily eliminate the need for the 'targets' instance variable by, for example, looking for methods within a certain method category, or for methods that begin (or end) with some common string, or even be more general by replacing 'targets includes: sel' with something like 'self respondsTo: sel', but I think I would prefer to keep strict control over what methods can be invoked via the URL with this scheme. So, I would use a 'targets' instance variable to explicitly define allowable methods that can be invoked with this scheme.
Nevin
On Thu, 27 Mar 2003, Nevin Pratt wrote:
- Define the URL for the 'red' link to be '/seaside/foo/red', and for
the 'green' link to be '/seaside/foo/green'.
<snip>
With the above, the 'red' and 'green' links will invoke the #red and #green target methods (respectively) of the component, just like a button does.
Forgive me if I'm being dense, but what's the point of all of this? What does this let you do that a simple
html anchorWithAction: [self red] text: ...
doesn't?
Is it so that you can have external links that cause a method to be invoked when you first enter the application?
Avi
Avi Bryant wrote:
Forgive me if I'm being dense, but what's the point of all of this? What does this let you do that a simple
html anchorWithAction: [self red] text: ...
doesn't?
Is it so that you can have external links that cause a method to be invoked when you first enter the application?
That was originally the primary motivation, and then once I saw I could do that, I didn't think to look beyond. Hence, I completely forgot about #anchorWithAction:text:, even though I had used it before.
However, I think even this use should probably be revisited, because the original motivation for having external links cause a method to be invoked was because of the desire to have multiple entry points into an application (i.e., static URL's). This would yield bookmarkable URL's, plus the ability to email a URL to someone that would enter the application at a known point when they clicked the URL that they were emailed (in such a case, they would not have a preconfigured bookmark, nor would they necessarily have ever entered the application before).
But, I suspect the WARegistry stuff could do the same thing. I'm just not clear on how to use it that way. Do you have any pointers or sample code that more fully explains how to use the WARegistry?
Nevin
Nevin Pratt wrote:
That was originally the primary motivation, and then once I saw I could do that, I didn't think to look beyond. Hence, I completely forgot about #anchorWithAction:text:, even though I had used it before.
However, I think even this use should probably be revisited, because the original motivation for having external links cause a method to be invoked was because of the desire to have multiple entry points into an application (i.e., static URL's). This would yield bookmarkable URL's, plus the ability to email a URL to someone that would enter the application at a known point when they clicked the URL that they were emailed (in such a case, they would not have a preconfigured bookmark, nor would they necessarily have ever entered the application before).
But, I suspect the WARegistry stuff could do the same thing. I'm just not clear on how to use it that way. Do you have any pointers or sample code that more fully explains how to use the WARegistry?
Nevin
Also, I currently have pluggable footers (for my test site), which can be swapped for various different footers. The footers are individual components, and are embedded in the main page(s) via their respective #renderContentOn: methods thus:
renderContentOn: html | footer | footer := { ... code to select an appropriate footer component ... } { ... other normal render code goes here ... } html render: footer
The footers sometimes have links that I wish to invoke a method of the main page component rather than a method of the footer component. If the links were created via the #renderContentOn: method of the footer via:
html anchorWithAction: [self someMethod] text: 'Some Text'
it would invoke the #someMethod of the footer component rather than the main page component that was embedding the footer.
So, I suppose that was another reason for my crazy scheme.
But in all such cases, I have the usual nagging suspicion that the overall architecture could be cleaner via another approach.
Nevin
For what it's worth, and if anybody cares, I rearchitected and eliminated this scheme from my test site.
Like a dummy, I didn't realize that this scheme would result in a new session being created when the link got clicked on.
Nevin
Nevin Pratt wrote:
Derek Brans wrote:
In Seaside, is there a way to have an anchor tag that will submit a form and perform an action (behaving just like a button)?
I've got a scheme that seems to work OK:
Suppose you've got a component 'Foo', with launch URL of 'http://localhost/seaside/foo' (or whatever machine and port you choose). Now, suppose the 'Foo' component has links 'red' and 'green' in the GUI, which you want to use to invoke methods #red and #green on component Foo when the links are clicked on.
- Define the URL for the 'red' link to be '/seaside/foo/red', and for
the 'green' link to be '/seaside/foo/green'.
- Give 'Foo' an instance variable called 'targets', and then create
an #initialize method of 'Foo' thus:
initialize targets _ OrderedCollection new. targets add: #red; add: #green
- Give 'Foo' a 'lastTarget' instance variable, which will be used to
prevent recursive circularities, as shown later.
- Put the following in Foo's #renderContentOn:
renderContentOn: html | path sel | path _ self session path. sel _ (path copyAfterLast: $/) asLegalSelector asSymbol. (lastTarget ~= sel and: [targets includes: sel]) ifTrue: [lastTarget _ sel. ^self perform: sel]. { ... the rest of the normal rendering code here ... }
With the above, the 'red' and 'green' links will invoke the #red and #green target methods (respectively) of the component, just like a button does.
You can, if you wish, easily eliminate the need for the 'targets' instance variable by, for example, looking for methods within a certain method category, or for methods that begin (or end) with some common string, or even be more general by replacing 'targets includes: sel' with something like 'self respondsTo: sel', but I think I would prefer to keep strict control over what methods can be invoked via the URL with this scheme. So, I would use a 'targets' instance variable to explicitly define allowable methods that can be invoked with this scheme.
Nevin
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
I've just updated our site to the latest SqueakMap version of Seaside.
However, the scheme I wrote about below no longer works for targeting different entry points into the app.
For example, if the browser URL is: http://localhost/seaside/foo/red then the 'path' variable in step #4 should return '/seaside/foo/red', so that I can invoke the #red method on the 'foo' component as explained in step #4.
But with this release, 'path := self session path' in step #4 just returns '/seaside/foo'. Thus, I have no idea what method of the 'foo' component the URL intends to invoke.
This forces me to have a single entry point into each component of the app, which forces me to rearchitect somewhat (unless I can find an alternative way to recreate the old behavior).
For example, when I wanted to give someone a URL that would take them directly to our 'View Cart' page, I would email them this:
http://www.bountifulbaby.com/seaside/index/viewcart
This would invoke the #viewcart method of the 'index' component, which would then take them to the shopping cart.
I suppose I could create a separate 'viewcart' entry point into the app via '/seaside/config', but I quite liked having the ability to invoke arbitrary methods on a component via the URL.
Any suggestions?
Nevin
************************ ************************ Derek Brans wrote:
In Seaside, is there a way to have an anchor tag that will submit a form and perform an action (behaving just like a button)?
I've got a scheme that seems to work OK:
Suppose you've got a component 'Foo', with launch URL of 'http://localhost/seaside/foo' (or whatever machine and port you choose). Now, suppose the 'Foo' component has links 'red' and 'green' in the GUI, which you want to use to invoke methods #red and #green on component Foo when the links are clicked on.
1. Define the URL for the 'red' link to be '/seaside/foo/red', and for the 'green' link to be '/seaside/foo/green'.
2. Give 'Foo' an instance variable called 'targets', and then create an #initialize method of 'Foo' thus:
initialize targets _ OrderedCollection new. targets add: #red; add: #green
3. Give 'Foo' a 'lastTarget' instance variable, which will be used to prevent recursive circularities, as shown later.
4. Put the following in Foo's #renderContentOn:
renderContentOn: html | path sel | path _ self session path. sel _ (path copyAfterLast: $/) asLegalSelector asSymbol. (lastTarget ~= sel and: [targets includes: sel]) ifTrue: [lastTarget _ sel. ^self perform: sel]. { ... the rest of the normal rendering code here ... }
With the above, the 'red' and 'green' links will invoke the #red and #green target methods (respectively) of the component, just like a button does.
You can, if you wish, easily eliminate the need for the 'targets' instance variable by, for example, looking for methods within a certain method category, or for methods that begin (or end) with some common string, or even be more general by replacing 'targets includes: sel' with something like 'self respondsTo: sel', but I think I would prefer to keep strict control over what methods can be invoked via the URL with this scheme. So, I would use a 'targets' instance variable to explicitly define allowable methods that can be invoked with this scheme.
Nevin
_______________________________________________ Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
On Fri, 13 Jun 2003, Nevin Pratt wrote:
I've just updated our site to the latest SqueakMap version of Seaside.
However, the scheme I wrote about below no longer works for targeting different entry points into the app.
For example, if the browser URL is: http://localhost/seaside/foo/red then the 'path' variable in step #4 should return '/seaside/foo/red', so that I can invoke the #red method on the 'foo' component as explained in step #4.
But with this release, 'path := self session path' in step #4 just returns '/seaside/foo'. Thus, I have no idea what method of the 'foo' component the URL intends to invoke.
How to handle complex URLs (which is, in my mind, related to how to enable bookmarking) is something I'm still not sure I've completely figured out, so I apologize that it keeps changing. Nevin, thanks for keeping doggedly on the bleeding edge.
However, the Wiki example does something similar (you can hit /seaside/wiki/SomePageName), and I keep it up to date, so it's a good place to look to figure out what the current approach is.
Currently the idea is to override WAControllerSession>>createRootFromRequest:. By default this creates a new instance of whatever class is set as the entryPoint preference, but you can examine the request and make a different choice if you need to.
Does that help?
Avi
Avi Bryant wrote:
Currently the idea is to override WAControllerSession>>createRootFromRequest:. By default this creates a new instance of whatever class is set as the entryPoint preference, but you can examine the request and make a different choice if you need to.
Does that help?
Avi
Yes. Thanks a bunch. I've got it working again.
You might recall a post a couple of days ago where I said I was upgrading the site as follows:
Going from Squeak 3.4 to Squeak 3.5 Going from Comanche 5.0.1 to Comanche 6.1 Going from PostgreSQL client 0.8.1 to 0.9 Going from Glorp 0.2.18 to Glorp 0.2.28 Going from Seaside 2.3b to whatever is on SqueakMap right now.
Well, I only went to Comanche 5.1.1 instead of 6.1, but otherwise upgraded everything else as indicated above. Comanche 6.1 is just too different, and I decided I was already biting off a pretty big upgrade chunk. So, I kept to the 5.x family for Comanche for now.
Things seem to be working. Hopefully I won't need to revisit any of this infrastructure for a few months, and can actually work on the site instead of infrastructure.
Nevin
All,
I have started a wiki page called "Promoting Seaside" http://swiki.squeakfoundation.org/sea/88 the idea being to promote the whole squeak-commanche-seaside package to be adopted in commercial web application environments.
For example - we know that squeak runs on all platforms, but others looking at seaside for the first time do not.
I am not saying we are at that stage yet, but will there come a time soon when we have a "standard" Squeak Image for developing web applications - stripped of eToys and Alice in Wonderland etc etc and loaded with database drivers, commanche, OSProcess, soap, xml, object serialisation etc etc. Something we could genuinely had over to a "design shop" and say "developing web applications is easy with this".
thoughts anyone
Keith
On Sat, 14 Jun 2003, Keith P. Hodges wrote:
I am not saying we are at that stage yet, but will there come a time soon when we have a "standard" Squeak Image for developing web applications - stripped of eToys and Alice in Wonderland etc etc and loaded with database drivers, commanche, OSProcess, soap, xml, object serialisation etc etc. Something we could genuinely had over to a "design shop" and say "developing web applications is easy with this".
thoughts anyone
Sure, I've always pictured things going that way - the expansion of SEASIDE is the Squeak Enterprise Aubergines Server Integrated Development Environment, and to me that implies exactly what you're describing: a squeak image loaded with enterprise tools and tweaked for web development.
I do wonder if there's any chance of convincing shops to use Seaside that aren't already Smalltalk friendly, however... seems somewhat unlikely.
Avi
Avi Bryant wrote:
I do wonder if there's any chance of convincing shops to use Seaside that aren't already Smalltalk friendly, however... seems somewhat unlikely.
Well, consider that IBM sold VisualAge Generator to mainframe folks without really telling them it was Smalltalk. VisualAge Generator is (as I understand) the same basic idea that Keith mentioned-- it's a framework built on VisualAge for Smalltalk, targeted for CICS "4GL" mainframe development. Here's their product blurb:
"IBM VisualAge® Generator is a powerful high-end, rapid application development environment for building and deploying e-business applications. Developers with little or no Java™ expertise can implement end-to-end Java e-business systems. OO and Java developers can implement systems running on traditional transactional platforms, such as CICS® or IMS, and accessing legacy data, such as DL/I or VSAM, with no need to become mainframe experts."
In fact, check their detailed product description at this link:
http://www-3.ibm.com/software/awdtools/visgen/
They don't mention "Smalltalk" anywhere.
And yet VisualAge Generator includes a full copy of VisualAge Smalltalk. VisualAge Generator is just a framework within it. And a VA/G license includes a full VA/S license (last time I checked, the cost of VA/G was about 50% more than the cost of VA/S, because of the extra framework of classes included).
And I understand quite a few VA/G license have been sold.
So, if we create and bundle a Seaside framework as Keith mentions, you never know what might transpire :-)
Nevin
The reason I started this was that I mentioned seaside on a mailing list of freelance workers in the uk and I got the response, "well what can it do", and didnt really know what to say... in terms of reaching my audience.
best regards
keith
Avi,
if am finding a need to have some kind of semantic messaging framework. Whereby and inner component can signal an action and the message propagates out through the containership heirarchy. The ability to register dependants would also be useful. I have used this successfully in the past.
any thoughts?
Keith
On Sat, 14 Jun 2003, Keith P. Hodges wrote:
Avi,
if am finding a need to have some kind of semantic messaging framework. Whereby and inner component can signal an action and the message propagates out through the containership heirarchy. The ability to register dependants would also be useful. I have used this successfully in the past.
Yes, some people may remember that there was briefly such a facility in Seaside 0.9x, inspired by NewtonScript - you could send "self container someMessage" and it would get picked up by the first enclosing component that could handle the message.
One goal I've had in Seaside 2.3 is to eliminate explicit parent links in components, to allow the component hierarchy to be as dynamic as possible. This has been a positive move, in my opinion, and I don't want to go back to enforcing a static hierarchy. This makes it hard to build in anything that traverses the containership tree.
However, you can certainly add and manage a 'parent' ivar in your own component subclasses...
And yes, some kind of standard dependents/event system for components might well be useful. What kind of thing were you thinking of using this for?
On Saturday, June 14, 2003, at 11:15 AM, Avi Bryant wrote:
I do wonder if there's any chance of convincing shops to use Seaside that aren't already Smalltalk friendly, however... seems somewhat unlikely.
Ooh. I have to disagree with that one. I became a Squeaker specifically to use Seaside. Now that I'm here, I've come to appreciate Smalltalk. I know that there are people out there using Python just because that's how Zope is implemented. Ditto Java and WebObjects.
Web applications are hard enough that (smart) people will be drawn into a good framework no matter what language it's in. The trick is to promote the framework, not the language. That's just an implementation detail.
-cwp
On Sat, Jun 14, 2003 at 03:14:14PM -0700, Colin Putney wrote:
On Saturday, June 14, 2003, at 11:15 AM, Avi Bryant wrote:
I do wonder if there's any chance of convincing shops to use Seaside that aren't already Smalltalk friendly, however... seems somewhat unlikely.
Ooh. I have to disagree with that one. I became a Squeaker specifically to use Seaside. Now that I'm here, I've come to appreciate Smalltalk. I know that there are people out there using Python just because that's how Zope is implemented. Ditto Java and WebObjects.
Same here.. i found out smalltalk about a year ago, and while Im still fihing with it, the reason I can put it to some use is seaside. Unfortunately a good number of web based projects require reuse of preexisting components (which are in other languages/frameworks) to be economically feasible. Or libraries, such as OpenLDAP..
Quoting Colin Putney cputney@wiresong.ca:
Ooh. I have to disagree with that one. I became a Squeaker specifically to use Seaside. Now that I'm here, I've come to appreciate Smalltalk. I know that there are people out there using Python just because that's how Zope is implemented. Ditto Java and WebObjects.
Web applications are hard enough that (smart) people will be drawn into a good framework no matter what language it's in. The trick is to promote the framework, not the language. That's just an implementation detail.
I have to agree with Colin on this one as well... I became a Squeaker looking for the Holy Grail of cross platform development for the platforms I cared about, for both desktop and web apps; it turns out that Seaside is becoming a major player in that... but I digress. In former lives, I mostly did web development, web infrastructure, or managed web teams; we frequently experimented with various systems, both commercial and open source, regardless of the specific language required from a programmer perspective, based on what capabilities the platform promised. I personally think Seaside is able to hold it's own in a lot of comparisions :)
Brian
On Saturday, June 14, 2003, at 04:14 PM, Colin Putney wrote:
I became a Squeaker specifically to use Seaside. Now that I'm here, I've come to appreciate Smalltalk. I know that there are people out there using Python just because that's how Zope is implemented. Ditto Java and WebObjects.
Web applications are hard enough that (smart) people will be drawn into a good framework no matter what language it's in. The trick is to promote the framework, not the language. That's just an implementation detail.
Oh I wish you could have explained that to Apple before they went and ported WebObjects from ObjectiveC to Java. But actually, language does matter somewhat. For instance, IMO, WebObjects did not survive the port to Java. The resulting system is much less productive to use. Hence my interest in Seaside.
-Todd
On Monday, June 16, 2003, at 11:16 AM, tblanchard@mac.com wrote:
Oh I wish you could have explained that to Apple before they went and ported WebObjects from ObjectiveC to Java. But actually, language does matter somewhat. For instance, IMO, WebObjects did not survive the port to Java. The resulting system is much less productive to use. Hence my interest in Seaside.
Actually, I did mention it to an Apple employee once... didn't seem to have much effect.
And yes, I agree that the language does matter. It's just that Seaside being in Smalltalk isn't as big a hurdle as it might seem, and may even be a vehicle for promoting Smalltalk.
Cheers,
Colin
Hi Folks:
Sure, I've always pictured things going that way - the expansion of SEASIDE is the Squeak Enterprise Aubergines Server Integrated Development Environment, and to me that implies exactly what you're describing: a squeak image loaded with enterprise tools and tweaked for web development.
OK, I agree, full agree, but I think also that the development of Squeak as a platform to continue expanding the frontiers of the software developmente must be maintained. Then, there would be an easy mode to transform a Squeak image in a "Seaside Web Production image" or in a "multimedia development image" or any another combination that the user (developer) need. Seems that the package system is on the way, but isn't sufficient yet. Seems that an a superior level of configuration is needed, that delimite the profile and target of the image to obtain.
I do wonder if there's any chance of convincing shops to use Seaside that aren't already Smalltalk friendly, however... seems somewhat unlikely.
One additional thing to take in account is the web hosting of the Seaside apps. If in a common Linux Server it's possible to host php or perl apps until quantities of 100-200 sites with good performance, with Seaside, running Squeak in a headless mode, a minimun of 32 MB ram must be assigned to each VM. Than means only 32 sites in a 1GB Server. I think that this is a main problem to solve to sell Seaside apps widely. Obviously that don't apply in a private Intranet or a private server.
But, to end, I agree in put all the possible info about commercial and "serious" use of Seaside as web development tool in a web site. Samples of working apps is also a good thing to take in account, as more detailed tutorials about development of Seaside apps.
Regards.
--- Germán S. Arduino http://www.dimensiono.com http://www.rva.com.ar
One additional thing to take in account is the web hosting of the Seaside apps. If in a common Linux Server it's possible to host php or perl apps until quantities of 100-200 sites with good performance, with Seaside, running Squeak in a headless mode, a minimun of 32 MB ram must be assigned to each VM.
I don't know about the requirements of Seaside itself but the above sounds pretty bogus to me. First of all, you should not consider an out-of-the-box Squeak+Seaside to be a Seaside production image. A *little* work on your end is to be expected and this work should probably include doing a little shrinking. Even with the most rudimentary methods you should be able to trivially get down to 16MB.
Secondly, IIRC, then Ian's latest VMs support dynamically growing and shrinking memory. In effect that means your SeaSide image will only consume as much memory as it really needs (modulo a bit of headroom which can be customized too). That means the initial requirement is just that of loading the image which, for a SeaSide production image, I would expect to be definitely less than 8MB.
Thirdly, there is swap space which you can throw at it. Most OSes these days make pretty good use of it so your division is a rather random guess considering that there are tons of objects in a "typical" Squeak image which can be swapped out without any negative side effects whatsoever.
All in all, I would claim that your stated "requirements" might be true - but only for an overly naive use of SeaSide in a production environment. If you just put your mind to it a little, you should be able to get *drastically* below that.
Cheers, - Andreas
PS. For marketing SeaSide it might be worthwhile to have a set of step-by-step instruction for how to make that "SeaSide production image" work.
Hi Andreas:
I don't know about the requirements of Seaside itself but the above sounds pretty bogus to me. First of all, you should not consider an
out-of-the-box
Squeak+Seaside to be a Seaside production image. A *little* work on your
end
is to be expected and this work should probably include doing a little shrinking. Even with the most rudimentary methods you should be able to trivially get down to 16MB.
Secondly, IIRC, then Ian's latest VMs support dynamically growing and shrinking memory. In effect that means your SeaSide image will only
consume
as much memory as it really needs (modulo a bit of headroom which can be customized too). That means the initial requirement is just that of
loading
the image which, for a SeaSide production image, I would expect to be definitely less than 8MB.
Would be very useful for me know how to get that small "seaside production image".
I've tried in one of the servers that I've to sell hosting and really 32MB was a minimun to several tasks, I've tried with Red Hat 7.3 and Squeak VM 3.4-1, but also take in account that myself aren't an expert in things as "shrinking".
Thirdly, there is swap space which you can throw at it. Most OSes these
days
make pretty good use of it so your division is a rather random guess considering that there are tons of objects in a "typical" Squeak image
which
can be swapped out without any negative side effects whatsoever.
All in all, I would claim that your stated "requirements" might be true - but only for an overly naive use of SeaSide in a production environment.
If
you just put your mind to it a little, you should be able to get *drastically* below that.
ok, you are right if a "production seaside image" may be managed with 8MB assigned to VM, then could by possible to host more than 100 sites in a server, making prices competitives with common hosting plans.
PS. For marketing SeaSide it might be worthwhile to have a set of step-by-step instruction for how to make that "SeaSide production image" work.
Yes, I full agree. I'm trying (as a learning project) to develop a simple weblog system using Seaside and the instructions to get a small "SeaSide production image" would be very useful for me.
Regards.
--- Germán S. Arduino http://www.dimensiono.com
Quoting "Germán S. Arduino" gsa@softhome.net:
One additional thing to take in account is the web hosting of the Seaside apps. If in a common Linux Server it's possible to host php or perl apps until quantities of 100-200 sites with good performance, with Seaside, running Squeak in a headless mode, a minimun of 32 MB ram must be assigned to each VM. Than means only 32 sites in a 1GB Server. I think that this is a main problem to solve to sell Seaside apps widely. Obviously that don't apply in a private Intranet or a private server.
A couple of other things to think about is the type of customer and what constitutues an "app". If you are talking about things Horde/Imp/phprojekt (freely available php web apps), then you most assuredly *not* going to run 100-200 sites on commodity hardware with decent performance.
Remember that it is possible to run many web apps inside of one seaside image; not necessarily for multiple customers, but if you are a web app shop building things for multiple customers and they are not actually doing the development, then you could certainly do this. Seaside is a very powerful framework for web apps, and I don't envision someone just needing a canned php guestbook or mail form using seaside, any more than I would envision them using WebObjects.
;-)
Brian
Brian Brown wrote:
Remember that it is possible to run many web apps inside of one seaside image;
I drive three different (and unrelated) domains from mine.
On Mon, 2003-06-16 at 06:43, Brian Brown wrote:
A couple of other things to think about is the type of customer and what constitutues an "app". If you are talking about things Horde/Imp/phprojekt (freely available php web apps), then you most assuredly *not* going to run 100-200 sites on commodity hardware with decent performance.
Furthermore, nothing in Seaside's architecture precludes *safely* running unrelated customer's web apps side-by-side in a single image. Something like Islands/SqueakE would be needed, of course, but if there starts to be a big need for such hosting environments they'll be built.
Also, I rent a virtual Linux box for 15 GBP per month - compared to web app development costs, that's virtually for free.
Keith P. Hodges wrote:
All,
I have started a wiki page called "Promoting Seaside" http://swiki.squeakfoundation.org/sea/88 the idea being to promote the whole squeak-commanche-seaside package to be adopted in commercial web application environments.
For example - we know that squeak runs on all platforms, but others looking at seaside for the first time do not.
I am not saying we are at that stage yet, but will there come a time soon when we have a "standard" Squeak Image for developing web applications - stripped of eToys and Alice in Wonderland etc etc and loaded with database drivers, commanche, OSProcess, soap, xml, object serialisation etc etc. Something we could genuinely had over to a "design shop" and say "developing web applications is easy with this".
thoughts anyone
Keith
Tool selection seems to always be a political decision in companies (commonly decided by mid-managers), rather than a technical one (decided by someone--anyone--with a genuine tech background).
But to help the politics:
Obviously the portability of Squeak across hardware is a plus.
But another thing that I think many corporate types would view as important is the fact that the Seaside framework itself is available on multiple dialects. They will perceive this as reducing their risk (although I personally just care about the Squeak port).
Our Bountiful Baby site can also be used as an example of a commercial Seaside site. I'd like to see others listed as well.
Keith P. Hodges wrote:
All,
I have started a wiki page called "Promoting Seaside" http://swiki.squeakfoundation.org/sea/88 the idea being to promote the whole squeak-commanche-seaside package to be adopted in commercial web application environments.
For example - we know that squeak runs on all platforms, but others looking at seaside for the first time do not.
I am not saying we are at that stage yet, but will there come a time soon when we have a "standard" Squeak Image for developing web applications - stripped of eToys and Alice in Wonderland etc etc and loaded with database drivers, commanche, OSProcess, soap, xml, object serialisation etc etc. Something we could genuinely had over to a "design shop" and say "developing web applications is easy with this".
Absolutely. This is definitely within the vision of the attempts to strip down the base image and provide customized images for various purposes. The job will get easier as the base image becomes smaller, but I don't think there's anything stopping someone from producing such an image now... it would just take a little more effort.
But I suspect Seaside has a little ways to go before it will be adopted at such a scale :) We need to, for example, address issues of and find solutions for scalibility, redundancy, designer/developer interaction, etc
Julian
Hi Keith
Avi and I were recently chatting about exactly this topic- creating a new webpage or wiki to promote Seaside!
Here some ideas we talked about:
- A "tour" showing what is exceptionel about Seaside This could be interactive like the WATutorial. It should show what features are there, what is possible, what is cool etc. E.g. control flow or use the integration of debugger (I find it really cool to push "debug" in the webbrowser, debug in the image and then say "proceed"! (compared for example to debugging in Zope)) and much more, of corse.
- A listing of successful/productiv/professional apps. There will be at least 5 already, I assume. Most of them are not public. But we could still make a listing with a short description of each project - maybe with a screenshot.
- Another ideas would be a FAQ, which could be compiled form the mailinglist.
So, a community effort to create this sites would be cool ! What I suppose to start with is to gather information and ideas on the wiki page, Keith has started (http://swiki.squeakfoundation.org/sea/88). Afterwards we'll maybe create a more designed version for the webpage.
Other ideas?
Adrian _____________________ Adrian Lienhard www.adrian-lienhard.ch www.netstyle.ch ----- Original Message ----- From: "Keith P. Hodges" keith.hodges@cheerful.com To: seaside@lists.squeakfoundation.org Sent: Saturday, June 14, 2003 7:21 PM Subject: [Seaside] Convincing Web Application shops to use seaside
All,
I have started a wiki page called "Promoting Seaside" http://swiki.squeakfoundation.org/sea/88 the idea being to promote the whole squeak-commanche-seaside package to be adopted in commercial web application environments.
For example - we know that squeak runs on all platforms, but others looking at seaside for the first time do not.
I am not saying we are at that stage yet, but will there come a time soon when we have a "standard" Squeak Image for developing web applications - stripped of eToys and Alice in Wonderland etc etc and loaded with database drivers, commanche, OSProcess, soap, xml, object serialisation etc etc. Something we could genuinely had over to a "design shop" and say "developing web applications is easy with this".
thoughts anyone
Keith
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
seaside@lists.squeakfoundation.org
-
Adrian Lienhard -
Andreas Raab -
Avi Bryant -
Brian Brown -
Brian Brown -
Cees de Groot -
Colin Putney -
Derek Brans -
Germán S. Arduino -
Julian Fitzell -
Keith P. Hodges -
Lukas Renggli -
Nevin Pratt -
Ragnar Hojland Espinosa -
tblanchard＠mac.com