Seaside vs. Traditional
Locked
123
123
 
|
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. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Randal L. Schwartz
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 _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside vs. Traditional
|
|
In reply to this post by Rob Rothwell
>>>>> "Rob" == Rob Rothwell <[hidden email]> writes:
>> From a business programming perspective, I don't want have to understand web Rob> page layout or need a CSS designer. I want to be able to drag components Rob> around on the screen, wire them up to my [well tested!] model, and have them Rob> behave as expected! Ahh. You're still living in the illusion that the Web is WYSIWYG. It isn't. Different browsers render things different ways. How will your app act on a browser that's twice as wide? Half as wide? Properly designed web applications are *not* done using Photoshop. They're constructed using sound design principles, to adapt to their environment. Create functional markup, and style it with CSS. Please. If people had done that properly, we wouldn't see this huge rush to now prepare "normal", "mobile" and now "iPhone" versions of sites. Gah! -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Lukas Renggli
Le samedi 29 mars 2008 à 17:31 +0100, Lukas Renggli a écrit : > > > > My feeling of Aida, is that it's closer to classic web (html I mean) > > > > and the nice feature is that anObject = anUrl. I would be curious to > > > > see the counter in Aida (implementation). > > > > > > Especially the multi-counter as a composition of counters would be > > > interesting, because this is where my troubles started when playing > > > with AIDA. > > > > Why? you can write a Counter as a subclass of WebElement if you want to > > reuse it, it would be really easy to write it in Aida too. > > Ok, then show me in terms of reusing the code at > http://nico.bioskop.fr/blog/seaside-counter-example-in-aida/web.html. But ok, I will write a multicounter example too, with a counter component. Nicolas > > Lukas > _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
signature.asc (196 bytes) |
|
In reply to this post by Randal L. Schwartz
On Sat, Mar 29, 2008 at 1:30 PM, Randal L. Schwartz <[hidden email]> wrote:
Ahh. You're still living in the illusion that the Web is WYSIWYG. It isn't. But do I have to know about that? Can't we create "meta-properties" that describe what we want the layout to be like under those circumstances, that are themselves built into the framework? Isn't that the type of useful abstraction Smalltalk is good at? You've already abstracted HTML...why not CSS as well? You know..."I want this component to grow to fit the page," or "I want that button to just remain that size." I'm not talking about rewriting CSS in Smalltalk, just making COMMON tasks more accessible. But, I'm probably still missing the point...boy, those 8 years in the Army sure left me out of the loop... Properly designed web applications are *not* done using Photoshop. They're So is there a way to...make that "easier" for mere mortals trying to throw a useful tool together for business users and use the web as a platform to avoid installation headaches and make use of the "liveliness" of Smalltalk? I still just think it's all about the interface to the components, not the components themselves if you REALLY want to attract a crowd. What I like about what you are saying is the "Model View Design" separation it would give you. It's just that the "Model View" portion is hard enough for me...let along getting a handle on the "Design" portion as well! I WANT to do the right thing! I just want it to be easier! Rob _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
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
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Rob Rothwell
On Sat, Mar 29, 2008 at 3:42 PM, blake <[hidden email]> wrote: On Sat, 29 Mar 2008 10:47:59 -0700, Rob Rothwell <[hidden email]> For what? Rob _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by cedreek
"cdrick" <[hidden email]> wrote in message
> But seriously, I think that will be good to have pro and cons for each > framework. Just hope discussion won't be too passionate then. That would really be great, specially if we learned where/how to best combine the two in a 100% Smalltalk solution. > Just hope discussion won't be too passionate then. >From all I have seen, I am sure folks like Janko, Lukas, Nicolas ... can be both passionate and objective :-) Sophie _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Lukas Renggli
Le samedi 29 mars 2008 à 16:43 +0100, Lukas Renggli a écrit : > > My feeling of Aida, is that it's closer to classic web (html I mean) > > and the nice feature is that anObject = anUrl. I would be curious to > > see the counter in Aida (implementation). > > Especially the multi-counter as a composition of counters would be > interesting, because this is where my troubles started when playing > with AIDA. I wrote a multi-counter: http://nico.bioskop.fr/blog/a-multi-counter-with-aida/web.html Cheers! Nicolas -- Nicolas Petton http://nico.bioskop.fr ___ ooooooo OOOOOOOOO |Smalltalk| OOOOOOOOO ooooooo \ / [|] -------------------------------- Ma clé PGP est disponible ici : http://nico.bioskop.fr/pgp-key.html _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Rob Rothwell
On 29-Mar-08, at 10:05 AM, Rob Rothwell wrote: > From a business programming perspective, I don't want have to > understand web page layout or need a CSS designer. I want to be > able to drag components around on the screen, wire them up to my > [well tested!] model, and have them behave as expected! Visual > Basic the way I always wanted it to work (from a model perspective) > only for the web! This sort of thing is possible, but it's not what Seaside provides - take a look at Dabble DB for draggable components. Seaside is not meant to make understanding the details of web programming unnecessary. It's meant to make dealing with those details convenient. Web programming normally involves a lot of code to translate state back and forth between various representations. Seaside establishes conventions for how that should be done, and abstractions that reduce the amount of code needed to work within the conventions. That's what people mean when they say the writing web apps in Seaside is "easy." They mean that it's a whole lot less work than is usual with web apps, not that they don't have to understand the web. If anything, writing Seaside apps is conceptually harder than "traditional" web frameworks, because you have to understand not only the web, but the conventions that Seaside uses and how to get the most out of them. The nice thing is that, once you've got all that under your belt, you rarely have to think about it any more. Rob, what is it that you want to accomplish? Perhaps Seaside isn't the right tool for the job. Colin _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
On Sat, Mar 29, 2008 at 9:26 PM, Colin Putney <[hidden email]> wrote:
That's what people mean when they say the writing web apps in Seaside Thank You! That would explain why over a week ago I wrote "I felt like I HAD to understand web programming and HTML just to make it work..."
If anything, writing Seaside apps is conceptually harder than Combine that with just trying to learn Smalltalk and no web experience... The nice thing is that, once you've got all that under True with just about any set of tools! Rob, what is it that you want to accomplish? Perhaps Seaside isn't the Well, work in a small (200 bed) community hospital that is just sinking under the weight of manual data abstraction from real, live, paper medical records. Hospitals have to report many "measures" to many agencies--government, insurance, watchdog, you name it. Many of these measures are "almost the same," but "just a little bit different" (subclasses). All the lists are based on patient populations obtained be constantly changing sets of rules which are in turn based on medical records coding.
Some of the data we need is actually stored (somewhere) in various databases. Some measures need data from 2 or more systems combined just to produce one piece of information. Almost all of them need additional information that, for now, is only obtainable by hand.
I settled on Smalltalk because I tried it with traditional Microsoft tools that were available to me, but I needed to be able to make changes easier because change is constant and not definable by rules in a configuration table somewhere. These NEED to be living objects.
We settled on a web app, while not ABSOLUTELY necessary, for many reasons, but the primary one is that we have very "non-technical" people that get confused by something "different," and they are currently comfortably using many web-based tools.
Anyway, I am in the beginning stages of connecting to various data sources, creating patient "work lists," and obtaining the data that IS available. Then, I need to be able provide these lists to multiple users to review, make manual changes if necessary (they often override the electronic data with manual data based on their abstraction rules), and then run the data through the various business logic rules to determine if the patient "passed" or "failed" the measure.
It was Magritte that initially attracted me to Seaside since they already worked together, because I thought you could probably do some very nice multi-field validation thing to apply the business logic and give feedback to the user. For example, if they enter a certain type of antibiotic AND the time it took to discontinue it was more than 2 hours AND the moon is full...you get the idea. They would like to turn the screen turn red or whatever to point out potential errors and so on.
So, with Aida I can quickly get text boxes and lists and calanders and buttons and so on up on the screen. But there IS a need for some heavy interaction between what they are entering and the various rules that apply to various types of patients under various circumstances. All of which needs to give them direct feedback, such as disabling, enabling, or even creating new fields and further changing the rules.
And then there are those pesky constantly changing rules. In a perfect world, I would like to let the users add and remove data points and change the logic as the rules change, because we only have myself and one other person [right now] who will possibly ever understand what the users know deeply from doing it all the time. Again, Magritte seemed a good candidate for that. We even pictured being able to read in the various documents from different vendors describing the rule changes and automatically make at least some of the changes, but that is definitely a future dream.
So you see, I was trying to keep the logic of interacting with the input fields and updating the display from turning all spaghetti-ish on me like it would if I worked like I always have, and the descriptions of Seaside and Magritte seemed to fit the bill. Aida has been a snap to get a patient list on the screen and pull up an individual patient with nicely tabbed views of various portions of the data, but I am concerned about my ability to keep the Model-View interaction clean enought to be bug-free as the rules change. I know that much of that work is actually in the Model, but, again, the Meta-Description capability of Magritte seemed like it could handle this very nicely.
Other than that, I don't need "pretty." Pretty can come later! I need basic field input, dropdowns, radio and check boxes, a few graphics to show them that their lists have changed since the last time they were there because the underlying data changed, that sort of thing. I can enforce the same browser and so one so I don't have to worry a lot about styles and so on.
This all seems VERY do-able with the tools that are available today. The changes are just piling up and we will start getting paid less or not at all for things that we either don't report, or do poorly on, so I don't want to be floundering to keep up with them!
Thanks again for your explanation. It was exactly what I was looking for! Rob _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Nicolas Petton
nicolas
what lukas means when he is talking about multicounter in seaside, is the ability to reuse witihin the same page exactly the same component (a counter for example) multiple times. in 2.8 children ^ {Counter new . Counter new . Counter new} I browsed your example and I could not see how it was working in Aida. 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. Stef On Mar 30, 2008, at 3:33 AM, Nicolas Petton wrote: > > Le samedi 29 mars 2008 à 16:43 +0100, Lukas Renggli a écrit : >>> My feeling of Aida, is that it's closer to classic web (html I mean) >>> and the nice feature is that anObject = anUrl. I would be curious to >>> see the counter in Aida (implementation). >> >> Especially the multi-counter as a composition of counters would be >> interesting, because this is where my troubles started when playing >> with AIDA. > > I wrote a multi-counter: > http://nico.bioskop.fr/blog/a-multi-counter-with-aida/web.html > > Cheers! > > Nicolas > -- > Nicolas Petton > http://nico.bioskop.fr > ___ > ooooooo > OOOOOOOOO > |Smalltalk| > OOOOOOOOO > ooooooo > \ / > [|] > -------------------------------- > Ma clé PGP est disponible ici : > http://nico.bioskop.fr/pgp-key.html > _______________________________________________ > 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 |
|
|
Nicolas
I clicked on your example so you can apparently do it. Now could you show how? Because I could not see how you specify the 4 or 5 instances. stef On Mar 30, 2008, at 12:08 PM, stephane ducasse wrote: > nicolas > > what lukas means when he is talking about multicounter in seaside, > is the ability to reuse witihin the same page exactly the same > component (a counter for example) > multiple times. > > > in 2.8 > > children > ^ {Counter new . Counter new . Counter new} > > > I browsed your example and I could not see how it was working in Aida. > 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. > > Stef > > On Mar 30, 2008, at 3:33 AM, Nicolas Petton wrote: > >> >> Le samedi 29 mars 2008 à 16:43 +0100, Lukas Renggli a écrit : >>>> My feeling of Aida, is that it's closer to classic web (html I >>>> mean) >>>> and the nice feature is that anObject = anUrl. I would be curious >>>> to >>>> see the counter in Aida (implementation). >>> >>> Especially the multi-counter as a composition of counters would be >>> interesting, because this is where my troubles started when playing >>> with AIDA. >> >> I wrote a multi-counter: >> http://nico.bioskop.fr/blog/a-multi-counter-with-aida/web.html >> >> Cheers! >> >> Nicolas >> -- >> Nicolas Petton >> http://nico.bioskop.fr >> ___ >> ooooooo >> OOOOOOOOO >> |Smalltalk| >> OOOOOOOOO >> ooooooo >> \ / >> [|] >> -------------------------------- >> Ma clé PGP est disponible ici : >> http://nico.bioskop.fr/pgp-key.html >> _______________________________________________ >> 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 > _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Rob Rothwell
Hi, is there any particular reason for comparing Seaside with another framework in a Seaside mailing list? If you're interested in Seaside, then use it. If you're interested in AIDA web, then use it. From my experience,
it seems that most frameworks were built or evolved to solve a particular problem and the developer(s) couldn't find a suitable choice and/or didn't like the available choice(s) in the existing frameworks. Next, I would
highly recommend learning Smalltallk to truly exploit the power of Seaside. This is true of any framework (i.e. learn Ruby to exploit Rails, learn PHP to exploit Zend Framework, learn C# or VB to exploit ASP.Net and so
on). Lastly, there are other pieces of the puzzle that one has to learn that go beyond simply learning the language of a framework. Good luck, -Conrad On Sat, Mar 29, 2008 at 8:05 AM, Rob Rothwell <[hidden email]> wrote: Hello... _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside vs. Traditional
|
|
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. Cheers Philippe > If you're interested in Seaside, then > use it. If you're interested in AIDA web, then use it. From my experience, > it seems that most frameworks were built or evolved to solve a particular > problem and the developer(s) couldn't find a suitable choice and/or didn't > like the available choice(s) in the existing frameworks. Next, I would > highly recommend learning Smalltallk to truly exploit the power of Seaside. > This is true of any framework (i.e. learn Ruby to exploit Rails, learn PHP > to exploit Zend Framework, learn C# or VB to exploit ASP.Net and so > on). Lastly, there are other pieces of the puzzle that one has to learn > that go beyond simply learning the language of a framework. > > Good luck, > > > -Conrad > > On Sat, Mar 29, 2008 at 8:05 AM, Rob Rothwell <[hidden email]> > wrote: > > > > 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 > > > > > > > > > > > > > > > > _______________________________________________ > > 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 > > seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
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. > 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. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Hi, in my short experience, it's well suited for both traditional and dynamic content. For example, when developing in raw XHTML sites, I have noticed a lot of duplication. How does one easily reuse chunks of
XHTML across an entire site without using server side includes? Seaside allows one to isolate these chunks
into neat components that can easily be used across their site(s). Next, I have always looked at a framework as a whole before determining its weakness. Just because Seaside doesn't have X feature that exists in framework Y doesn't necessary count this as a weakness in Seaside. Why? This may be a feature that's not needed at all within Seaside because it does other things very well and/or there exists a better or another way to do it. Finally, I don't want to see the Seaside framework cluttered with stuff that it really doesn't need when their exists better ways of solving the problem with the existing functionality.
-Conrad On Sun, Mar 30, 2008 at 5:23 AM, cdrick <[hidden email]> wrote: 2008/3/30, Philippe Marschall <[hidden email]>: _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by cedreek
"cdrick" <[hidden email]> wrote in message
> 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). I asked a related question recently on this list http://www.nabble.com/How-to-mark-not-cacheable--td14849804.html#a14849804 - Not sure if I interpreted the responses correctly, e.g. http://www.nabble.com/Re%3A-Re%3A-Re%3A-How-to-mark-not-cacheable--p14912182.html but it sounded like the back button is *supposed* to return to a client-side exact re-rendering of the page as that client last saw it. To me it seems the "always refreshed" is cleaner on the server (though it might have some extra requests) and easier to the user as well. Sophie _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by stephane ducasse
Hi Stéphane,
Sorry, I thought it was obvious: In an application I have some instances of counters (components), and in a view method (#viewMain in the demo), a add them: viewMain |e| e := WebElement new. self counters do: [:each | e add: each]. self pageFrameWith: e title: 'multi-counters' Cheers! Nicolas _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by stephane ducasse
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 |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |