Getting yourself a Virtual Private Server hosting account is the easiest and cheapest way to get started with deploying your apps in any sort of dynamic language.
This is what I use, myself, at the moment. Advantage: Low cost, you have full root access to the OS Disadvantage: Self-managed you have to provide the system administration , low disk space compared to dedicated servers — VPSs have from Gb of disk space , slower than dedicated physical servers. I polled my web app developer friends recently, as to what sort of hosting service they use they are mostly Ruby and Python developers.
Out of those, Digital Ocean has the best value, although Linode has is more established and highly regarded for business use. Pharocloud looks very promising. Amazon Elastic Compute Cloud EC2 For not much more cost per month than a medium-size VPS, you can also deploy your Seaside application to the cloud, which gets you load balancing, unlimited scaling capability, and more. Deployment to EC2 — Resources:.
Fortunately, these are still fairly inexpensive compared to what they used to cost even a few years ago. You have two options: Unmanaged Servers they give you a physcal box and remote access, just like with a VPS, and you provide the system administration. You can also choose Managed Servers , where the host provides you with a box and performs system administration for you, guarantees your uptime and manages your security.
Subscribe to RSS
Seaside Hosting offers free MB hosting partitions for non-commercial Seaside applications see the chapter on deploying to SeasideHosting of the Seaside book, and the Seaside hosting Pharocast. This is where the official Seaside site is hosted, for instance. Disadvantage: For non-commercial apps only, MB disk limit, no shell access or access to databases so, you basically store your data in the image. For free, these are obviously going to be small and underpowered hosting accounts, with not much memory, diskspace or bandwidth provided.
The only one of these free shell services I have experience with is the SDF Lonestar organization — and hey, it does what it says on the box. Advantage: Free. Develop it, and put it up on a free hosting service above for beta testing.
When you outgrow free hosting and need more power or disk space, or bandwidth … you should just ask. Ask on the mailing lists Seaside, Squeak, Pharo , ask individual developers or universities… Doors will be opened to you. Each day, an un-commented class would be picked from the Pharo class hierarchy, and people on the list would propose comments for the class which would then be added to the next release.
This is a great idea, not to mention hilarious. Comments especially class comments are worth their weight in gold, and this is an easy and low-key way to slowly improve the quality of the codebase. Not to mention harnessing the wisdom of the crowds, etc. Satuday, the release of JNIPort 2. This is excellent news — the more interoperability options the Smalltalk ecosystem has, the better. I look forward to checking out the library. Earlier this month, Tony Fleig announced a new package, TFLogin to handle some common web app tasks — user authentication, registration and account management. The caller is temporarily replaced by the callee, until the callee returns control by sending answer:.
The caller is usually self , but could also be any other currently visible component.
A workflow can be defined as a task. Instead of defining renderContentOn: , it defines no content of its own, but rather defines a go method that sends a series of call: messages to activate various subcomponents in turn. There is a trivial example of call: and answer: in the rendering demo of Figure 0. The component SeasideEditCallDemo displays a text field and an edit link.
The callback for the edit link calls a new instance of SeasideEditAnswerDemo initialized to the value of the text field. The callback also updates this text field to the result which is sent as an answer. What is particularly elegant is that the code makes absolutely no reference to the new web page that must be created. At run-time, a new page is created in which the SeasideEditCallDemo component is replaced by a SeasideEditAnswerDemo component; the parent component and the other peer components are untouched.
It is important to keep in mind that call: and answer: should never be used while rendering. They may safely be sent from within a callback, or from within the go method of a task. The SeasideEditAnswerDemo component is also remarkably simple. It just renders a form with a text field.
The submit button is bound to a callback that will answer the final value of the text field. Seaside takes care of the control flow and the correct rendering of all the components. Interestingly, the Back button of the browser will also work just fine though side effects are not rolled back unless we take additional steps. Since certain call—answer dialogues are very common, Seaside provides some convenience methods to save you the trouble of writing components like SeasideEditAnswerDemo. The generated dialogues are shown in Figure 0. Some standard dialogs.
The message request: performs a call to a component that will let you edit a text field. The component answers the edited string. An optional label and default value may also be specified. The message inform: calls a component that simply displays the argument message and waits for the user to click Ok. The called component just returns self.
Smalltalk Zen | Web Development with Pharo Smalltalk and Seaside
The message confirm: asks a question and waits for the user to select either Yes or No. The component answers a boolean, which can be used to perform further actions. A few further convenience methods, such as chooseFrom:caption: , are defined in the convenience protocol of WAComponent. A task is a component that subclasses WATask. It does not render anything itself, but simply calls other components in a control flow defined by implementing the method go.
- Re: Seaside One Click Experience on Pharo 4?;
- Ashes in my mouth, sand in my shoes : stories;
- The Essential Guide for Smokers.
- Tom Phoenix.
- The finite difference time domain method for electromagnetism?
- Using Informative Assessments Towards Effective Literacy Instruction?
- Home Chiropractic Handbook.
This task calls in turn three components. The first, generated by the convenience method chooseFrom: caption: , is a WAChoiceDialog that asks the user to choose a cheese. Finally a WAFormDialog is called via the convenience method inform:. A simple task. We saw in Section 0. Sometimes, however, we do not want to backtrack state: instead we want to prevent the user from accidentally undoing effects that should be permanent.
This is often referred to as "the shopping cart problem". Once you have checked out your shopping cart and paid for the items you have purchased, it should not be possible to go Back with the browser and add more items to the shopping cart!
Object-Oriented Programming, Design with TDD in Pharo
Seaside allows you to enforce restriction this by defining a task within which certain actions are grouped together as transactions. You can backtrack within a transaction, but once a transaction is complete, you can no longer go back to it. The corresponding pages are invalidated , and any attempt to go back to them will cause Seaside to generate a warning and redirect the user to the most recent valid page. The Sushi Store.
The Seaside Sushi Store is sample application that illustrates many of the features of Seaside, including transactions. If you toggle the halos, you will see that the top-level component of the sushi store is an instance of WAStore. It does nothing but render the title bar, and then it renders task , an instance of WAStoreTask. WAStoreTask captures this workflow sequence. At a couple of points it is critical that the user not be able to go back and change the submitted information.
Purchase some sushi and then use the Back button to try to put more sushi into your cart. Seaside lets the programmer say that a certain part of a workflow acts like a transaction: once the transaction is complete, the user cannot go back and undo it. This is done by sending isolate: to a task with the transactional block as its argument.
We can see this in the sushi store workflow as follows:. Here we see quite clearly that there are two transactions. The first fills the cart and closes the shopping phase. The helper methods such as fillCart take care of instantiating and calling the right subcomponents. Once you have confirmed the contents of the cart you cannot go back without starting a new session. The second transaction completes the shipping and payment data.
You can navigate back and forth within the second transaction until you confirm payment. However, once both transactions are complete, any attempt to navigate back will fail. Transactions may also be nested.