Hi,
Just thought I would introduce myself. I'm new to this group, and very interested in Squeak and Seaside. I'm a 30 year veteran of computer wars. Having first started programming in 1977 in APL in high school. Now, I'm a professional developer, have worked all over the US and in Europe and develop web applications in Java. I started out using WebObjects and am now using a variety of horrible J2EE frameworks. After 30 years of TPS rreports and corporate manuvering, I'd pretty much lost my interest in development. It had become just a job. The horrible movement back in time from WebObjects to J2EE didn't help the situation. Squeak and Seaside have piqued my interest in developing again. In a way that I haven't felt in a long time. So I'm very interested in best practices. I'm hoping that if I can develop a good enough grounding in this stuff that I can suggest we try Seaside as a development platform where I work. I have my fingers crossed. So now on to the question: Imagine you're writing a game and you have a player object. There are places in the game where you want to display player information on the page you are generating. I would say classically that the player is the Model. and that Seaside gives us the View. So now my question is, about the Controller. Is the controller a separate class? Should there be a controller class that handles placing the data from the model onto the page? Or should the page just know about the player and make direct calls into the player object. If I have a component, PlayerInfoView. Is that in fact the controller? I guess my question is about boundaries. Should the player object know anything about seaside? I'm trying to understand the basic layout of how these pieces fit together and I'm looking for one or more of you to chime in with your general feeling about the way this kind of issue gets resolved. Tony Giaccone. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
2008/11/21 Tony Giaccone <[hidden email]>:
> Hi, > > Just thought I would introduce myself. I'm new to this group, and very > interested in Squeak and Seaside. I'm a 30 year veteran of computer wars. > Having first started programming in 1977 in APL in high school. Now, I'm a > professional developer, have worked all over the US and in Europe and > develop web applications in Java. I started out using WebObjects and am now > using a variety of horrible J2EE frameworks. > > After 30 years of TPS rreports and corporate manuvering, I'd pretty much > lost my interest in development. It had become just a job. The horrible > movement back in time from WebObjects to J2EE didn't help the situation. > Squeak and Seaside have piqued my interest in developing again. In a way > that I haven't felt in a long time. So I'm very interested in best > practices. I'm hoping that if I can develop a good enough grounding in this > stuff that I can suggest we try Seaside as a development platform where I > work. I have my fingers crossed. > > So now on to the question: > > Imagine you're writing a game and you have a player object. There are > places in the game where you want to display player information on the page > you are generating. I would say classically that the player is the Model. > and that Seaside gives us the View. So now my question is, about the > Controller. There is no real controller. View related actions to the component. Model related actions to the model. > Is the controller a separate class? Should there be a controller class that > handles placing the data from the model onto the page? Or should the page > just know about the player and make direct calls into the player object. Yes. A component is kinda like view and controller together. > If I have a component, PlayerInfoView. Is that in fact the controller? > > Should the player object know > anything about seaside? No. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Most Seaside applications don't require you to write much controller
functionality. The hard work is done behind the scenes by the Seaside callback handlers. As Philippe writes, the small controller methods are usually combined with the view (subclass of WAComponent). Usually method categories are used to keep view and controller code apart, by convention these categories are named #rendering and #actions. Lukas On Fri, Nov 21, 2008 at 3:47 PM, Philippe Marschall <[hidden email]> wrote: > 2008/11/21 Tony Giaccone <[hidden email]>: >> Hi, >> >> Just thought I would introduce myself. I'm new to this group, and very >> interested in Squeak and Seaside. I'm a 30 year veteran of computer wars. >> Having first started programming in 1977 in APL in high school. Now, I'm a >> professional developer, have worked all over the US and in Europe and >> develop web applications in Java. I started out using WebObjects and am now >> using a variety of horrible J2EE frameworks. >> >> After 30 years of TPS rreports and corporate manuvering, I'd pretty much >> lost my interest in development. It had become just a job. The horrible >> movement back in time from WebObjects to J2EE didn't help the situation. >> Squeak and Seaside have piqued my interest in developing again. In a way >> that I haven't felt in a long time. So I'm very interested in best >> practices. I'm hoping that if I can develop a good enough grounding in this >> stuff that I can suggest we try Seaside as a development platform where I >> work. I have my fingers crossed. >> >> So now on to the question: >> >> Imagine you're writing a game and you have a player object. There are >> places in the game where you want to display player information on the page >> you are generating. I would say classically that the player is the Model. >> and that Seaside gives us the View. So now my question is, about the >> Controller. > > There is no real controller. View related actions to the component. > Model related actions to the model. > >> Is the controller a separate class? Should there be a controller class that >> handles placing the data from the model onto the page? Or should the page >> just know about the player and make direct calls into the player object. > > Yes. A component is kinda like view and controller together. > >> If I have a component, PlayerInfoView. Is that in fact the controller? >> >> Should the player object know >> anything about seaside? > > No. > > Cheers > Philippe > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Free forum by Nabble | Edit this page |