What are the differences between the three Smalltalk web application frameworks?
Some starting points:
What is the sweet spot for each framework? in Which case would you use one or the other?
What are their weaknesses?
Which one has the cleanest URLs?
How do they handle Ajax?
Do they have some preference in their use of persistence?
I'm just trying to decide which framework is appropriate for each kind of application.
I can only answer for Seaside:
Target: Seaside targets complex web applications with focus on reusability and development productivity. There is automatic session state management and back-button support. The two free online books Dynamic Web Development with Seaside and Seaside Tutorial provide documentation.
Weakness: For RESTful URLs you have to do some extra work.
Clean URLs: For RESTful URLs you have to do some extra work, but it can be worth it (e.g. Pier).
AJAX: There are plenty of AJAX libraries integrated in Seaside (jQuery, jQueryUI, Prototype, script.aculo.us, ...). The integrations give you full access to these libraries from within Smalltalk. New libraries can be easily integrated, e.g. JQueryWidgetBox.
Persistency: Seaside is a web application framework, not a persistency framework. You can use whatever persistency solution fits you the best, e.g. GemStone, GOODS, GLORP, ...
Also see these other questions/discussions on StackOverflow:
What is the difference between Seaside programmming and other web programming
Is Seaside still a valid option?
I can say something on the Iliad side:
Sweet spot(s): It handles AJAX painlessly. For me, that was the turning point that made me switch to Iliad. Also, it's so small and non-bloated that you can read the whole code in a day and have a grasp on how it works.
Weaknesses: The community is also very small. This results in a lack of documentation, additional modules or pre-made widgets. OTOH, small communities tend to be willing to help each other more eagerly, so pretty much all your doubts can be solved by asking at the mailing list.
URLs: Well, since all calls in Iliad are AJAX by default, the URL stays clean the whole time.
Ajax: Yep. For free and by default. You just #markDirty a widget and it'll update automatically. Dependencies are as easy to define as sending #addDependantWidget: to a widget, so that when the first is marked dirty, both will be updated. Also, if the client doesn't have a javascript capable browser, all calls will fall back to regular HTTP requests automatically.
Persistence: No preference. Since the model is separated from the framework (I think this applies for the three frameworks) you can still follow the same guidelines you would for Aida or Seaside.
And for Aida/Web:
Sweet spots: Realtime web support out of the box, for both content websites and complex web apps, HTML5 and mobile support, web server included so it works immediately after installation, you can serve many virtual websites from the same image.
Weaknesses: lack of documentation, small community
URLs: clean REST-like URLs all the time, because Aida follows from the start the moto: every domain object can have its URL (also by Alan Kay) and domain object can even choose its URL by itself.
Ajax: Seamlessly integrated, you don't see it anymore, all is just there. To refresh some element on webpage you simply call e update. No need to know any jQuery or some other JavaScript. Same goes for realtime web apps as well. WebSocket protocol is default communication channel on supported browsers to exchange JSON messages between browser and Aida based server.
Persistence: Image based persistence with automatic snapshot every hour is turned on by default. Gemstone/GLASS support provided for the next step. Relational/other DB is a duty of domain level, if needed.
For more:
Comparison of Smalltalk web frameworks from Aida centric
perspective
ToDo example in Aida/Web shows the newest realtime web/HTML5
features, as part of Comparison by example initiative
For some persistency solutions for Seaside, there is a page. Most of the solutions there are independent of Seaside.
Related
What would be good (cross Smalltalk, mantained, documented) web frameworks or packages (in terms of fewer things to learn/adapt) to use for implementing a static web site with really few forms? .i.e. : a search box and a contact form. I have no "model" or application behind, so I'm not searching for CMS or web application capabilities.
There is any example or simple script of a static web site developed in any web frameworks? please I'm NOT interested in counter or 'Hello World' examples. The examples I've seen from Seaside looks too complicated, too many nested blocks with the "programmatic HTML" and the ones I've seen from AIDA needed a model object, couldn't figure how to get something working without a model.
All Smalltalk web-servers (Zinc, Kom, and Swazoo) can serve static files. If you take Pharo 1.3, Zinc is already pre-loaded. Just look at the code, tests and comments and you should get a server running in no time.
All Smalltalk web-servers (Zinc, Kom, and Swazoo) can serve static files. If you take Pharo 1.3, Zinc is already pre-loaded. Just look at the code, tests and comments and you should get a server running in no time. (via Lukas Renggli)
Taking some performance hit, you can have Seaside serve content as though it was static.
I know this question is too wide to be answered with a simple "use this framework", but I would really appreciate your advice on that one.
I'm looking to make a (quite complex) project than will run over an API. I'm open to any programming language (PHP, Python, Java mostly) and found many frameworks that are more oriented to make a RESTful web server.
The only major constraint I have is that I would have a reusable, simple and not-code-spaghetti independent package in order to improve my API later easily or even switch to an other framework with no pain.
For Python & Java, I thought about making a dedicated package. Each action would call the dedicated method in the package, the package would return object/dict and the action would transform it to the proper format.
After many research, I hesitate between two framework that could be good for my work but I need your advice because I wouldn't make any mistakes here.
Play! Framework (Java)
Pros :
Router are RESTFul oriented (you define the method (GET, POST, etc), the request and the class.method to use)
You don't have to make one class per action
Cons :
The Model is already included. If I later change the framework, maybe I will be stuck with it (but apparently not since Play! seems to use JPA)
Maybe the fact that if I want to send parameters to the action that would be defined in the method signature, I have to adopt the ClassName.properties instead of a json like {ClassName: {properties: 'value'}}
Tornado Web (Python)
Pros :
Seems to be very powerful : used by FriendFeed (at least) !
Auth via major OpenId, OAuth and Facebook already implemented
Very light (could be a problem)
Cons :
Not so popular : you understand better the work by going into the code than the doc
Urls seems to be very basics (As far as I saw it, you have to define all the urls in one file, with all the class included)
One Class per action (that could be heavy)
Decorators for the basic (testing if user is auth, etc) must be made
For using them in production, it would be easily possible with apache & mod_proxy or nginx.
So, my questions is quite simple : what would you choose (between those two or others, I'm not closed to suggestions) and why ?
Thank you really much for your advice!
My favorite RESTful Web App development framework is Restlet. It's a Java framework/library (it can be thought of as either) but it works well with Jython and JRuby, so if you prefer those languages you could still use it. I mostly use it with Groovy.
I prefer Restlet because:
Its API fully embraces and aligns with RESTful paradigms, so it encourages you to work RESTfully. For example, when a Router routes a request to a ServerResource, it creates a new instance of the ServerResource for every request. This encourages the implementation to be stateless. And there's a rich class hierarchy with all the concepts required to implement a RESTful web app: Client, Server, Protocol, VirtualHost, Request, Response, MediaType, Status, etc.
Its API includes classes for writing both servers and clients, and they're very consistent and almost symmetrical. For example, there's a ServerResource class and a ClientResource class. ServerResource.get() and ClientResource.get() both return a Representation. The only difference is that you implement ServerResource.get() and generate a response representation, while you call ClientResource.get() and receive a response representation.
The API is consistent with Java conventions. For example, if a request made with ClientResource.get() receives an error response such as 401, a ResourceException will be thrown. And if you're implementing a ServerResource and want to return an error status, you just throw a ResourceException (which is a RuntimeException, which is nice).
Via its extension mechanism, it plays very nicely with a broad array of the best Java libraries around. Extensions are included for various HTTP client and server libraries, databases, templating libraries, security libs, data libs such as XML, JSON, OAuth, OData, etc., and even OSGI.
Deployment is very flexible. You can embed a Restlet-powered API in an existing Java app, an existing Java Servlet app, or any standard Java Web App (Servlet) server. Or you can build a stand-alone server app with an embedded HTTP server such as Jetty — that's my preferred approach. And because it runs on the JVM, it runs on almost any hardware or OS.
It's mature, reliable, responsibly maintained, steadily improving, and well supported both by the community and commercially.
It's open source, and has very clear and well-structured code. The developers are happy to accept any contributions. I've submitted a few patches and had them committed to trunk quickly with no drama.
Other options I'd suggest would be the Python microframework Bottle and the Ruby microframework Sinatra. They're both simple, straightforward, lightweight, and effective. And because they work with the WSGI and Rack stacks, there's a rich set of "middleware" modules which can easily be used with them.
As background, I currently develop for a university, and we have problems with departments demanding "web 2.0 content" and accessibility requirements.
How do really big sites that are JavaScript based deal with 508 Compliance? Some sites degrade, and others require enabling JavaScript. How much impact does one decision have versus the other?
Also, in a realistic sense, how much development time should be devoted the accessible versions of sites versus the "main" versions?
I'm a blind developer and find it possible to use many Web 2.0 sites - this is most certainly possible.
Firstly, I strongly advise against making a separae accessible site, regardless of how many people advise you to do this. This is bad practice and will end up being more work, even if it initialy seems simpler.
Next, try to use progressive enhancement (particularly if this is a new site). Code the site without any Javascript; it's not just accessibility which benefits. Then, in your OnLoad() go through and attach Click events to the anchor tags; this way if you have Javascript you'll see the Ajax version, otherwise you will have a full page refresh and see another HTML page.
Luckily, there is a new standard, WAI-Aria (www.w3.org/WAI/intro/aria.php) which makes this much simpler. You attach attributes to HTML tags to identify the semantics of an Ajax control, for example. The only problem with Aria is that it only works with newer screen readers and web browsers. The university may well require the site be accessible to people running older software.
I'm a screen reader user and often use Javascript enabled sites. Javascript is not an accessibility issue, the way it is used can be. For example if the site uses javascript that requires the use of a mouse and doesn't have keyboard alternatives it will not be 508 compliant. An example of a site that uses Javascript and is accessible is stackoverflow.com. The only feature that isn't accessible is the ability to determine if you have accepted an answer to a question. I would take a look at the links in Annie's answer. All the blind college students I know use a fairly modern browser with Javascript enabled, Lynx is no longer popular in the blind community. If you want to try using a screen reader a good open source one for windows can be found at
http://www.nvda-project.org/
and it works well with firefox. If you want to try using the web with out Javascript install the Noscript addin.
Sites don't have to disable JavaScript to be accessible. Many sites use ARIA roles to work better with screen readers. There's a giant list of articles on accessible AJAX applications here. You could try something like AxsJAX.
I've been recommended the Click framework from Apache. But I can't find any forums talking about benchmark, reviews, advantages, disavantages, usefulness, ease of implementation, etc.
I've been asked to use it to develop a web site, but I'm completly in the dark about its strengths and weaknesses.
And its damn name isn't helping !! Click ? Hey Apache ! Call your next framework "the" just for fun. I dare you.
So can anyone comment on his experience with Click ?
What I personally like about the Click framework is that it is fairly close to HTML/HTTP and the Servlet API. There is no huge abstraction to get familiar with. You have a Page class, a Form class, ... If you need to preserve state across invocations you put it in the session or you pass it through the URL... This makes it easy to start using it. It is also straightforward to control the HTML pages being generated. It may sound like it is a very basic framework but the simplicity is actually one of it greatest strengths.
Other frameworks (e.g. Seam) are more suitedr to create a very large web application with lots of reusable components and complicated pageflows but the learning curve is much steeper. So for me Click works well for small to medium sized websites.
It's an apache incubator project but that does not mean the project is not stable, rather it reflects that it is in transition to the Apache project model.
Click is Apache's version of a component based web framework equivalent to JSF (other component base Java Frameworks are Tapestry and Wicket)
Click is rated at Ohloh
There is an official blog and some Wikipedia references: Framework Comparision and info page
In the bad old days of interactive console applications, Don Libes created a tool called Expect, which enabled you to write Tcl scripts that interacted with these applications, much as a user would. Expect had two tremendous benefits:
It was possible to script interactions that otherwise would have had to be repeated by hand, tediously. A classic example was dialup Internet access hell (from the days before PPP).
It was possible to write scripts to test one's own interactive applications, programmatically, as part of a regression suite.
Today most interactive applications are on the web, not on the console. Hence my question: is there any tool that provides the ability to interact with web pages and web forms programmatically, much as Expect provides the ability to interact with console applications programmatically?
(The closest thing I am aware of is Chickenfoot.)
You might be looking for Selenium
I've used Selenium RC in conjunction with Python to drive web page interactions programmatically. This has allowed me to write pretty extensive user tests in which forms and inputs are driven and their results are measured.
Check out the Selenium IDE on Firefox (as mentioned above). It allows you to record tests in the browser and play them back, either using the IDE itself, or the Remote Control app.
Perl Mechanize works pretty well for this exact issue.
HTTPS and some authentication issues are tricky at times. I will be posting couple questions about those in the future.
I did a ton of Expect work in a former life and always thought Don Libes' Expect book was one of the best-written and most enlightening technical books I'd ever seen.
Hands down I would say that Perl's WWW::Mechanize library is what you want. I note above that you were having trouble finding documentation. There is good documentation for it! Look up the module's distribution on search.cpan.org and see what all is packaged with it. There's a FAQ, Cookbook with examples, etc. Plus I've always been able to get help on the web. If you can't get it here, try at use.perl.org or perlmonks.org. WWW::Mechanize's author, Andy Lester, is present on Stack Overflow. (He's also an all around friendly and helpful guy.)
I believe WWW::Mechanize also has a program that is analogous to Expect's autoexpect program: you set up a proxy process running this program as a server, point your browser to it as a proxy, perform the actions you want to automate, and then the proxy program gives you a WWW::Mechanize program for you to use as a base for your project. (If it works like autoexpect, you will certainly want to make modifications from there.)
As mentioned above, WWW::Mechanize is a browser (to be more exact, it is a web client or http client) that happens to be programmable. The last time I looked, there was even work in progress to make it support JavaScript.
In addition to Selenium, if you're doing the Ruby/Rails thing, there's Webrat.