Stefan Krecher wrote:
i'd like to know if there are some best-practices/ patterns for seaside application architectures.
- The first thing you need when you start creating production quality code instead of prototypes/spikes, is a CI environment, where you pull code from the open source projects you use - Start with categories for domain model, tests and web - Don't do the whole architecture up front, drive it from the code - Drive the domain model from tests - Keep the code well refactored, DRY - Create a declarative description of the domain model; Magritte provides a good starting point. You need better descriptions for behavior, relationships, validation. - Generate web components by introspection. - Use a hexagonal architecture. - Persistence is an implementation detail, to be decided on ALAP - In the component model of Seaside a component has children; the child does not have an explicit parent (as there might be more than one). The child uses announcements to inform its parent. - In development, break up the css into many methods - Refactor - The reflective capabilities of Smalltalk allow fairly large architectural changes to be made with little effort. Learn how to manipulate your project's source code - Development is done in a MOOSE image, so you can visualize the code quality over time. - Did I tell you to refactor?
Stephan Eggermont
Stephan, thank you very much for these detailed Tips - this is extremly helpul! regards, Stefan
Am 2. April 2012 23:14 schrieb Stephan Eggermont stephan@stack.nl:
Stefan Krecher wrote:
i'd like to know if there are some best-practices/ patterns for seaside application architectures.
- The first thing you need when you start creating production
quality code instead of prototypes/spikes, is a CI environment, where you pull code from the open source projects you use
- Start with categories for domain model, tests and web
- Don't do the whole architecture up front, drive it from the code
- Drive the domain model from tests
- Keep the code well refactored, DRY
- Create a declarative description of the domain model;
Magritte provides a good starting point. You need better descriptions for behavior, relationships, validation.
- Generate web components by introspection.
- Use a hexagonal architecture.
- Persistence is an implementation detail, to be decided on ALAP
- In the component model of Seaside a component has children;
the child does not have an explicit parent (as there might be more than one). The child uses announcements to inform its parent.
- In development, break up the css into many methods
- Refactor
- The reflective capabilities of Smalltalk allow fairly large architectural
changes to be made with little effort. Learn how to manipulate your project's source code
- Development is done in a MOOSE image, so you can visualize
the code quality over time.
- Did I tell you to refactor?
Stephan Eggermont
Hi Stefan
It mostly is a good idea to keep the css reasonably static and in one or a few files That allows caching and reduces the number of roundtrips needed for the page to load.
In Magritte there are many ways to achieve this, depending on where you want the responsibility to be. You could override the componentClass and override the edit:. At a certain point you might want a custom form renderer.
In the few cases where I've needed custom css, I also had a custom component where I could render the css inline, or do a calculation trick:
canvas div class: 'column kols',nrOfColumns asString;
with in the css
.kols1{ width: 100%; } .kols2{ width: 48%; } .kols3{ width: 32%; }
Stephan
p.s. Any specific reason you're not using the shorthand classes: #(HistorieArbeitsbereiche); accessor: #historieArbeitsbereiche;
Hi Stephan,
2013/3/14 Stephan Eggermont stephan@stack.nl:
In Magritte there are many ways to achieve this, depending on where you want the responsibility to be. You could override the componentClass and override the edit:. At a certain point you might want a custom form renderer.
i wasn't aware of this possibility - setting componentClass and overwriting edit: works perfect for me!
Any specific reason you're not using the shorthand classes: #(HistorieArbeitsbereiche); accessor: #historieArbeitsbereiche;
i copy-pasted from another example - does the accessor really work this way? It is a one-to-many-relationship, where elements are added to a collection.
thanks, Stefan
Stefan,
The accessor actually calls the "asAccessor". So If you want to know how it really works, look up the implementors of asAccessor. But yes, I think just using a symbol for a "standard" accessor, makes it much more readable.
Regards, Diego
On Mar 15, 2013, at 9:56 AM, Stefan Krecher wrote:
Hi Stephan,
2013/3/14 Stephan Eggermont stephan@stack.nl:
In Magritte there are many ways to achieve this, depending on where you want the responsibility to be. You could override the componentClass and override the edit:. At a certain point you might want a custom form renderer.
i wasn't aware of this possibility - setting componentClass and overwriting edit: works perfect for me!
Any specific reason you're not using the shorthand classes: #(HistorieArbeitsbereiche); accessor: #historieArbeitsbereiche;
i copy-pasted from another example - does the accessor really work this way? It is a one-to-many-relationship, where elements are added to a collection.
thanks, Stefan
-- Dipl.-Wirtsch.-Inf. Stefan Krecher Neulander Str. 17, 27374 Visselhövede Tel +49(0)4262 958848 mobil +49(0)172 3608616 http://krecher.com _______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Hi Stefan,
Thanks for the summary! I have some questions though:
- Create a declarative description of the domain model; Magritte provides a good starting point. You need better descriptions for behavior, relationships, validation.
How do you do it?
- Use a hexagonal architecture.
What is it?
- In development, break up the css into many methods
I prefer to keep my CSS and complex Javascript separate (and use a text editor to edit it)... Having something like less/scss in a Smalltalk DSL could be nice though.
- Development is done in a MOOSE image, so you can visualize the code quality over time.
That's quite a good one, thanks for the tips!
Cheers, Francois
seaside@lists.squeakfoundation.org
-
Diego Lont -
Francois Stephany -
Stefan Krecher -
Stephan Eggermont