Re: Best-practices/ architectural patterns for business apps

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
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Stephan,
thank you very much for these detailed Tips - this is extremly helpul!
regards,
Stefan

Am 2. April 2012 23:14 schrieb Stephan Eggermont <[hidden email]>:


--
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
[hidden email]
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 mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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;

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi Stephan,

2013/3/14 Stephan Eggermont <[hidden email]>:
> 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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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:

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside