Seaside vs. Traditional
Locked
 
|
Hello...
I would like explore a little further the post "Seaside vs. Traditional" at http://www.lukas-renggli.ch/blog? because:
1. I was a sound bite! ("As a new Smalltalker, I couldn't understand Seaside.") Kind of embarrassing, huh?!
2. This post did not fully help me understand the source of my inabilities! Even more embarrassing!
The two basic statements I am [mostly] referencing are:
1. I've experienced this many times while giving dozens of tutorials on Seaside. There are always some people that have a very hard time to get their head around Seaside, mostly because they think in terms of TRADITIONAL WEB FRAMEWORKS (my emphasis). 2. On the other hand, Seaside is AMAZINGLY SIMPLE (my emphasis) for people without MUCH (my emphasis) prior web development experience. Well, unfortunately, I have NO prior web development experience. And I mean NONE. Look at me, I have copied and pasted from another site and now have indents (likely due to HTML that I don't understand) that I can't even get rid of in the Gmail editor! Anyway, I completely skipped that part of the 21st century, much to my current dismay. I have Assembly Language, FORTRAN, and Visual Basic experience. I am the classic [boring] example of "Why does the world seem inside out in Smalltalk!" Nonetheless, I became enchanted by "a better way," and have stuck with my attempts to learn Smalltalk for nearly four years, most of which has been spent "building images" with each new Squeak release and staring at an "empty browser." I have a degree in Physics, I have been "programming" since I was 11, and I was a U.S. Army Airborne Ranger Medic. Smalltalk has been the first thing in my life that was ever hard for me! So...fun! But...frustrating, because I wanted to get real WORK done with it, and kept going back to obviously "lesser ways" just to get something done. Ok. Enough background. The point I am trying to make is that I tried. I googled. I would meet a couple of guys once a month or so that CAN Smalltalk. Seaside made sense...when they were doing it! Then, I went back to the empty browser. My impression is still that you need to have a certain level of accomplishment in Smalltalk itself before the...elegance...of the framework as at your disposal. This isn't a bad thing, although it does leave me feeling a little incapable, but, hey--the number of objects at your command when you open a Squeak image for the first time are simply overwhelming. And "overwhelmed" would be how I would describe my experience with Seaside to be, because it "looks so easy," so why can't I figure it out? Which, coincidentally, is EXACTLY how I feel watching an experienced Smalltalker do ANYTHING. So, I agree with you. Seaside IS harder for those with a "traditional" background. But I think traditional includes standard static language programming to produce basic client applications for typical operating systems. And from THAT point of view, I feel like I don't understand web programming ENOUGH to even lay things out on the screen where I want them to be, or get images into my application (yes, basic stuff like that). And so then there is Aida as well, which WAS easier coming from a "traditional" (my definition) background. Now, I do not want to be thwarted so easily and will surely continue to try to understand Seaside because I think that will help me continue to understand Smalltalk. But WHY was Aida easier for me? Is it because it is "less powerful?" "More procedural?" Because I CAN lay things out on the screen quite easily "the wrong way" with tables? Is it more "concrete?" These are all "negative" phrases as if I should assume somehow that Seaside has the upper hand in some way I do not understand. I obviously don't have the answers! I didn't even know Aida existed until Janko posted his benchmarks on the Cincom site and because I was struggling with Seaside I gave it a shot. I DO think that after spending some time with Aida, I will be able to understand Seaside better, which is MOST interesting, because somewhere in that thought lies the gap between my own process capability (my ability to simply use Smalltalk) and the capability demanded by the system (Seaside, Aida, or any set of classes for that matter), which is the classic gap inherent in any system implementation. Anyway, if I can figure this out better, I may be able to help others succeed where I have struggled, because I am obviously missing something. In the meantime, keep up the good work! I am intrigued by the "meta" abilities of your solutions with both Seaside and Magritte and their apparent ability to act as an elegantly abstract layer for Content--which could be useful in appropriately complex situations. Unfortunately, I don't think I'm ready yet. Maybe someday...when I grow up, and can handle that level of abstraction! I hope this doesn't sound like the beginning of another "Us vs. Them" post. I've had enough of that with LPGL vs. MIT! I just want to understand...what I don't understand! Anyone going to the Smalltalk Solutions conference? I am trying to position myself to go...maybe in the shear presence of mastery I can pick up on some of the stuff I am missing! Rob _______________________________________________ Aida mailing list [hidden email] http://lists.aidaweb.si/mailman/listinfo/aida |
|
|
Rob Rothwell wrote:
> 1. I was a sound bite! ("As a new Smalltalker, I couldn't understand > Seaside.") Kind of embarrassing, huh?! Just answering to the Smalltalk side of things. In my experience looking at people learning Smalltalk there are a few things more or less special about learning Smalltalk: - it is a language that is orders of magnitude easier to learn with someone mentoring you (best sitting next to you) - it takes a decent programmer about three months until they hear this loud clicking noise in their head: the switch being thrown to think the Smalltalk (OO) way. And there will be no way back - good programmers become more productive, not so good ones become less productive in Smalltalk compared to other languages - there are actually people who don't get it. At all. But those are rare, fortunately Why is this not the same in e.g. Java? You can cheat and avoid OO ;-) Just MTC € Michael _______________________________________________ Aida mailing list [hidden email] http://lists.aidaweb.si/mailman/listinfo/aida |
|
|
On Sat, Mar 29, 2008 at 11:53 AM, Michael Rueger <[hidden email]> wrote:
Unfortunately, this is not available to me! - it takes a decent programmer about three months until they hear this Is that with the mentor?! Actually, the switch has been thrown...I am able to do some useful work now, and I hate having to go back and support my previous work.
- good programmers become more productive, not so good ones become less I don't know if I'm good or not; I've never really worked with anyone else. I just use computers to solve typical automation problems in healthcare...most of which has to do with moving and checking data with constantantly changing requirements and lots of natural "subclasses." Smalltalk is the obvious choice. There are some "small" solutions that come out of our Six Sigma projects. I THINK I am...becoming...more productive, but just enforcing the TOOLS is bogging me down (writing tests, saving my projects, change sets, all that stuff), let alone writing CODE.
- there are actually people who don't get it. At all. But those are Yes...fortunately. I NEED this, or we will never be able to keep up with the changing world of healthcare and the gaps that need to be filled between our purchased products and our process capabilites. We need fast flexibility to provide short bursts of important automation!
Why is this not the same in e.g. Java? You can cheat and avoid OO ;-) I never learned Java. Only used C when I had to. Was frustrated by VB for years but I knew how to get something done. Just MTC € I agree...I'm just not good enough yet for all the work I have to get done! But I have finally turned a corner, and am hopeful of speedier progress!
Rob _______________________________________________ Aida mailing list [hidden email] http://lists.aidaweb.si/mailman/listinfo/aida |
|
|
<quote author="Rob Rothwell-2">
I agree...I'm just not good enough yet for all the work I have to get done! But I have finally turned a corner, and am hopeful of speedier progress! Rob, Most of us went through the same sort of frustration. For me, I had been programming in ST for a while and in 1989 or 90, I was given a task where I had to draw relationships between entities on a diagram following all kinds of rules, like they cant overlap, be hidden by an entity, etc. It was at that point that my expert C, Forth and Assembler skills utterly failed me. I remember sitting in my Hotel room and starting again, but this time thinking about the lines being smart, asking the entities things, having the "canvas" give me hints, etc. The light had been turned on. I pulled it off, the Data Modeler was in use at American Airlines for years (might still be) and I have been an OO programmer ever since. You seem very bright, soon it will be second nature. Best of luck. Leon |
|
|
In reply to this post by Rob Rothwell
Test Driven Development make thath you object model work always as you say may work. If you do "something wrong", the tests will say you to solve it. Or I didn't understand you correctly? El 29/03/2008, a las 17:08, Rob Rothwell escribió:
_______________________________________________ Aida mailing list [hidden email] http://lists.aidaweb.si/mailman/listinfo/aida |
|
|
On Sat, Mar 29, 2008 at 12:23 PM, Giuseppe Luigi Punzi Ruiz <[hidden email]> wrote:
I just meant that I enforcing these good practices takes some effort at first. When you are not used to writing tests, you have to change your process. Which will be useful, because right now all my "tests" are in HUGE workspaces (a likely beginners mistake, I'm sure). Most of my problems, though, use databases, so I am having a hard time enforcing myself to "setUp" the TestCase by "creating" the types of data that exist in my database so that I won't be dependent on the database to run the test. By the way, your English is MUCH better than my Spanish! Rob _______________________________________________ Aida mailing list [hidden email] http://lists.aidaweb.si/mailman/listinfo/aida |
Re: [Seaside] Seaside vs. Traditional
|
|
In reply to this post by Rob Rothwell
On Sat, Mar 29, 2008 at 1:09 PM, Lukas Renggli <[hidden email]> wrote: Another minor detail is that when I open a new browser window I get This is how Janko explained it to me... Rob --------------------------------------------------------- That's completely right and expected Aida behavior, because from both browsers you look at the same domain object. But see the further answer below. > Furthermore, if I enter the site from the same computer in two different > browsers and add "self inspect" at the top of MyObjectApp>>viewMain, I > the app instance seems to be the same. instance) or two different browsers, like IE and FF? In first case it is natural that you see just one session because by just opening a new window you don't open a new session but reusing an existing one. In later case you should have two separate sessions. _______________________________________________ Aida mailing list [hidden email] http://lists.aidaweb.si/mailman/listinfo/aida |
Re: [Seaside] Seaside vs. Traditional
|
|
In reply to this post by Rob Rothwell
On Sat, Mar 29, 2008 at 1:26 PM, Randal L. Schwartz <[hidden email]> wrote:
I'll be there. I have an invited talk on "Persistence Solutions using Sounds like a lot of fun; I hope the trip gets approved for me, but we are a community hospital struggling to make 3%! However, it's cheap, as conferences go! I'll have to sleep a lot beforehand, though, so I can try everything out at night...! Rob _______________________________________________ Aida mailing list [hidden email] http://lists.aidaweb.si/mailman/listinfo/aida |
Re: [Seaside] Seaside vs. Traditional
|
|
In reply to this post by Rob Rothwell
Thanks for all the great energy on a Saturday afternoon!
What I take from this is that everyone wants to make it... Better? Easier? More? But...what that means, what the vision of the future looks like is the probably where the work is. It's not WILL you program web applications in the future, it's HOW will you program web applications in the future?
How can we automate standard work? Across multiple browsers? Across multiple platforms? It's so close you can taste it! All the tools are just sitting there! I agree with Giuseppe,
"...and all us, smalltalkers, needs to see this 2 frameworks grow to trample Ruby on Rails, and all other frameworks to conquest the world muahahahahahaha (devil laugh)" Thanks again...I have a lot to think about...!
Rob
_______________________________________________ Aida mailing list [hidden email] http://lists.aidaweb.si/mailman/listinfo/aida |
|
|
In reply to this post by Rob Rothwell
2008/3/30, Philippe Marschall <[hidden email]>:
> 2008/3/30, Conrad Taylor <[hidden email]>: > > > Hi, is there any particular reason for comparing Seaside with another > > framework in a Seaside mailing list? > > > Yes, I truly believe so. To better understand for which tasks Seaside > isn't suite, what problems people have with Seaside and of course what > strengths and advantages Seaside has over other frameworks. > same... I feel seaside attracts lots of people and most of the time, they want just want to realize "classic web content" even if dynamic too. So Seaside is not particularly well suited. Especially since Pier can be the way to do such tasks in seaside...Precisions on strenghts of frameworks will really help whether seaside or whatever else. I think Sophie and Ramon picked up the framework really quickly for good reasons (even if apparently they had two different background with in common a good OO understanding ; Ramon was already a web dev and Sophie was new to web apps). Maybe they can help here. Colin explains it well too. My 2 cents about differences after my little investigations... I think the main visible difference between aida and seaside is the back button story (aiders correct me if I'm wrong) which allow different kind of apps. Seaside allows natively to track or not track state (variables and objets interaction), to isolate some flow too... But this is an extra job too. Aida back button will bring you "back, your page will be refreshed and you'll have a new, not old state of that object. A valid one, always" (quoted from Janko). Also, I notice removing cookies support in your broser enable different sessions in the same browser. But when hitting button in aida, there seems to be no registration in the browser history (so no back possibility) and this is not done in ajax. Both are ok to me. We just need to know. So what I call Desktop like app is total control on entries whereas classical web forms may not need this complexity. Note I don't say that Aida can't do that but it seems to me natively supported by seaside. Cheers, Cédrick ps: As a side note, discussion started on both lists (aida + seaside), but when answering I think we lost one and they it became two separate posts on both lists. So I add this mail to aida. _______________________________________________ Aida mailing list [hidden email] http://lists.aidaweb.si/mailman/listinfo/aida |
|
|
In reply to this post by Rob Rothwell
Hi Stef,
Let me first rename topic to Seaside vs. Aida, because that's more appropriate to the Lucas blog post anyway. He pointed to other "traditional" frameworks, not Aida :) stephane ducasse wrote: > Now I think that there is room for seaside and aida side by side. It > would be nice if both frameworks would mention their own limits. > It seems that in Aida you cannot easily embed multiple times the > same component on a page. Ok, let me start explaining Aida's component model more broadly, because it seems that is one of major misunderstandings when comparing both frameworks. Reason seems to be simply in naming and nothing more. In Aida we have a WebElement which start covering primitive elements like images, links or text, and ends up to the whole web page. WebElement can namely be a composite of sub elements down to primitive ones. We have therefore a consistent component model from a web page down to primitive elements. Just recently we started using a name "component" and introduce a class WebComponent (which is currently just an empty subclass of WebElement) to more clearly separate components from mere elements. But where elements end and components begin, that's now a question. Components are supposed to be a standalone, reusable, heavy ajaxified parts of web page, but that's already every web element in Aida! Introduction of WebComponent class is therefore currently more conceptual than practical, but we hope it will evolve in practicality through the time. Let me allow to make a short comparison with a Seaside component model. Here a web page is a root component and you can have also subcomponents (children). So far so good, we are the same. First difference is how those components (say web pages) are connected and how user navigates among them, another difference is how both component models continue building a web page down to a primitive elements. Let we look at later for now. In Seaside you start painting a component, using a hierarchy of blocks. In Aida you continue building with smaller and smaller WebElements. Aida therefore continue using consistently the same component model down to the lowest level of web pages: basic text, images etc. One of the consequences of this consistency is how long are methods in Aida. You'll see that almost all are short, inside 10 line recommendation. I think this shows well the strengths of Aida component model. Other is maybe that users find Aida easy to use. Maybe. Let me finish with a component model example. That's how it looks a page creation method for squeak.org demo http://squeaksite.aidaweb.si : pageElement | e t | e := WebElement newId: #container. self headerElementTo: e. t := WebElement new. t table width: 1; cellSpacing: 0; cellPadding: 0. t cell valign: #top. t cell table cellSpacing: 0; cellPadding: 0. t cell cell add: self menuElement. t cell newRow. t cell cell add: self linksElement. t cell newRow. t cell cell add: self sideLogosElement. t newCell valign: #top; add: self bodyElement. "contents" t newCell valign: #top. t cell table cellSpacing: 0; cellPadding: 0. t cell cell add: self downloadsElement. t cell newRow. t cell cell add: self newsElement. t cell newRow. e add: t. ^e ...then header element: headerElementTo: e e add: self headerLinksElement. e add: self headerTitleElement. e add: self headerActionsElement. e add: self headerSessionElement. ... and finally login part in up right corner: headerLoginElement | e | e := WebElement newDiv. self session isLoggedIn ifTrue: [e addText: self app session user nameSurname, ' | '. e addLinkTo: self site admin text: 'Logout' view: #logout] ifFalse: [e addLinkTo: self site admin text: 'Login' view: #login]. ^e Best regards Janko -- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si _______________________________________________ Aida mailing list [hidden email] http://lists.aidaweb.si/mailman/listinfo/aida |
|
|
stephane ducasse wrote:
> ok I see > but could you show the code of the multicounter example that nicolas > mentioned. > because I could not see how you got the 4 counters in a row. I suppose that he did an equivalent of such code: viewMAin | e | e := WebElement new. e add: CounterComponent new; add: CounterComponent new; add: CounterComponent new; add: CounterComponent new. self pageFrameWith: e title: 'multicounter'. So it is actually the same way as you show in your Seaside example. Janko > On Mar 30, 2008, at 9:33 PM, Janko Mivšek wrote: > >> Hi Stef, >> >> Let me first rename topic to Seaside vs. Aida, because that's more >> appropriate to the Lucas blog post anyway. He pointed to other >> "traditional" frameworks, not Aida :) >> >> stephane ducasse wrote: >> >>> Now I think that there is room for seaside and aida side by side. It >>> would be nice if both frameworks would mention their own limits. >> > It seems that in Aida you cannot easily embed multiple times the >>> same component on a page. >> >> Ok, let me start explaining Aida's component model more broadly, >> because it seems that is one of major misunderstandings when comparing >> both frameworks. Reason seems to be simply in naming and nothing more. >> >> In Aida we have a WebElement which start covering primitive elements >> like images, links or text, and ends up to the whole web page. >> WebElement can namely be a composite of sub elements down to primitive >> ones. We have therefore a consistent component model from a web page >> down to primitive elements. >> >> Just recently we started using a name "component" and introduce a >> class WebComponent (which is currently just an empty subclass of >> WebElement) to more clearly separate components from mere elements. >> But where elements end and components begin, that's now a question. >> >> Components are supposed to be a standalone, reusable, heavy ajaxified >> parts of web page, but that's already every web element in Aida! >> Introduction of WebComponent class is therefore currently more >> conceptual than practical, but we hope it will evolve in practicality >> through the time. >> >> Let me allow to make a short comparison with a Seaside component >> model. Here a web page is a root component and you can have also >> subcomponents (children). So far so good, we are the same. >> >> First difference is how those components (say web pages) are connected >> and how user navigates among them, another difference is how both >> component models continue building a web page down to a primitive >> elements. Let we look at later for now. >> >> In Seaside you start painting a component, using a hierarchy of >> blocks. In Aida you continue building with smaller and smaller >> WebElements. Aida therefore continue using consistently the same >> component model down to the lowest level of web pages: basic text, >> images etc. >> >> One of the consequences of this consistency is how long are methods in >> Aida. You'll see that almost all are short, inside 10 line >> recommendation. I think this shows well the strengths of Aida >> component model. Other is maybe that users find Aida easy to use. Maybe. >> >> Let me finish with a component model example. That's how it looks a >> page creation method for squeak.org demo http://squeaksite.aidaweb.si : >> >> pageElement >> | e t | >> e := WebElement newId: #container. >> self headerElementTo: e. >> t := WebElement new. >> t table width: 1; cellSpacing: 0; cellPadding: 0. >> t cell valign: #top. t cell table cellSpacing: 0; cellPadding: 0. >> t cell cell add: self menuElement. t cell newRow. >> t cell cell add: self linksElement. t cell newRow. >> t cell cell add: self sideLogosElement. >> t newCell valign: #top; >> add: self bodyElement. "contents" >> t newCell valign: #top. t cell table cellSpacing: 0; cellPadding: 0. >> t cell cell add: self downloadsElement. t cell newRow. >> t cell cell add: self newsElement. t cell newRow. >> e add: t. >> ^e >> >> ...then header element: >> >> headerElementTo: e >> e add: self headerLinksElement. >> e add: self headerTitleElement. >> e add: self headerActionsElement. >> e add: self headerSessionElement. >> >> ... and finally login part in up right corner: >> >> headerLoginElement >> | e | >> e := WebElement newDiv. >> self session isLoggedIn >> ifTrue: >> [e addText: self app session user nameSurname, ' | '. >> e addLinkTo: self site admin text: 'Logout' view: #logout] >> ifFalse: >> [e addLinkTo: self site admin text: 'Login' view: #login]. >> ^e >> >> >> Best regards >> Janko >> >> >> >> >> --Janko Mivšek >> AIDA/Web >> Smalltalk Web Application Server >> http://www.aidaweb.si >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > -- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si _______________________________________________ Aida mailing list [hidden email] http://lists.aidaweb.si/mailman/listinfo/aida |
|
|
In reply to this post by Janko Mivšek
Hi Sophie,
itsme213 wrote: > I think this has some real advantages (like Michael Lucas-Smith's earlier > post), though I am not sure of the trade-offs. Lukas explained earlier that > Seaside uses explicit Components and their #children to do several things... > >> 1. parse the initial request (#initialRequest:) >> 2. change the current URL (#updateUrl:) >> 3. register objects for backtracking (#updateStates:) >> 4. render something to the XHTML head (#updateRoot:) >> 5. render something to the XHTML body (#renderContentOn:) >> 6. process callbacks (#processCallbackStream:) > > Does Aida handle these elsewhere? How would a "component" hook into or > customize any of 1-6? 1-2: Url resolution: first, in Aida url always point to the domain object and not to a Component as in Seaside. Domain object then in MVC fashion delegates the request to its so called WebApplication (shorter: App) which is responsible for VC part of MVC. Domain object needs to therefore have a corresponding App class. Counter needs CounterApp. This App is then roughly the same as Seaside's root component. 3: Backtracking: Aida don't have backtracking. Why no, maybe later. 4-5: Rendering: is a two step in Aida: first building the object presentation of page, then serializing it into HTML. After an App receives a request (actually a #printWebPage call) it starts building a kind of object DOM tree of page. Then a #printHTMLPage is sent to render a page into HTML. This two step process has advantages like freedom of order how you build a page or "late binding" of page header info and also that you can render in something else instead of HTML. Main disadvantage is that it takes more time. 6. Actions: Aida don't have callbacks but are actions in MVC fashion strictly separated in separate methods, which are implemented in Apps. For instance for view #viewMain you can have an action in method #actionMain. Also form data posting is automatic directly to the domain objects. Usually you'll see such code in Aida: e addInputFieldAspect: #name for: self observee Here we add an input field to edit a name of a domain object (named observee, in accordance to Observer pattern). But we are thinking on introduction callback like server side validation of form input fields. Here the callbacks won't intermix too much the presentation code with action and business logic, which we'd like to keep separated, in the spirit of MVC paradigm. > Also, does Aida have anything like (or have you any plan for something like) > Scriptaculous, to allow talking to client-side Javascript from pure > Smalltalk? Yes, Prototype and Scriptaculous JS libraries are there by default and deeply integrated into Aida. Prototype is always loaded (needed for Ajax) while Scriptaculous is loaded on demand. Ajax support in Aida is one of its major strengths. For instance if you'd like to send input field immediately after something is entered, you would simply: aField onChangePost ...and field will be Ajax posted automatically. Such deep integration allows us now to ajaxify all new applications, because this brings so big benefit to users for so small cost. >> In Seaside you start painting a component, using a hierarchy of blocks. >> In Aida you continue building with smaller and smaller WebElements. > > Yes, render html vs. construct DOM tree. > > Perhaps the "hierarchy of blocks" part can be seen as just an API style, and > could also be used as an API to construct a DOM tree behind the scenes, > where Seaside's #div, #anchor, #table, etc. would construct DOM nodes, and > #with: would start constructing the sub-tree ? Here I actually see the possibility to learn something from each other and I'm already thinking of introducing a simpler page building syntax with recent Seaside syntax as an example. Here Seasiders would also profit to extend component model to be more fine grained, with simpler and shorter methods as a first consequence. Best regards Janko -- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si _______________________________________________ Aida mailing list [hidden email] http://lists.aidaweb.si/mailman/listinfo/aida |
«
Return to AIDA/Web
|
1 view|%1 views
| Free forum by Nabble | Edit this page |