Smalltalk › Frameworks & Tools › Seaside › Seaside General

Component granularity & numbers

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Sophie424

Component granularity & numbers

Is it reasonable to have one component for every appearance of any domain
model object on the page (could be hundreds, many of them being presented
just as very summarized names without their details) plus one component for
every control (menu etc.)?

Are there drawbacks to explicitly giving IDs to the corresponding top-level
html elements corresponding to these components?

Seems clean, but I would like some general design guidance. Should I instead
have some components traverse & present from multiple levels of the domain
model without creating children components to do that work, and what might
be my criteria to decide?

Thanks - Sophie

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

Yanni Chiu

Re: Component granularity & numbers

itsme213 wrote:
> Is it reasonable to have one component for every appearance of any domain
> model object on the page (could be hundreds, many of them being presented
> just as very summarized names without their details) plus one component for
> every control (menu etc.)?

It depends on your model. If "domain model object" means an application
UI model that interacts with an underlying business model, then the
answer is yes. If the model objects are the underlying business objects
themselves, then the answer is maybe. It'll work well if your UI is
mostly CRUD-like (i.e. create/retrieve/update/delete). The approach will
start to break down when the underlying business objects have more
specialized behaviour. You'll know you've reached the tipping point when
you have to keep extending your generic framework code to accomodate
your business model. Hope that helps.

--
Yanni Chiu

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

Sophie424

Re: Component granularity & numbers

"Yanni Chiu" <[hidden email]> wrote
> The approach will start to break down when the underlying business objects
> have more specialized behaviour.

If by "specialized behaviors" you mean things that typically involve some
sequence of user interaction, primarily dealt with by WATask or Ajax
equivalents, I include these as well. I think much of these can be automated
by generic components + suitable metadata. I'd be interested in other kinds
of things you consider exceptions as well.

I was looking more for guidance on plain scale of # of components. If a page
shows 5 primary domain objects in some detail, but show another 100 domain
objects in summary, some of them multiple times (e.g. just their names),
should I use 105+ components instances or just 5?

Thanks - Sophie

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

Sebastian Sastre-2

RE: Re: Component granularity & numbers

Is your domain model design scalable, clean and simple? Is your application
domain design scalable, clean and simple? Is the browsing experience good
enough? If so what would be the problem of having 1500 components in one
page?

Perhaps I'm not understanding your question.

Cheers,

Sebastian

> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]] En nombre
> de itsme213
> Enviado el: Sábado, 05 de Enero de 2008 05:00
> Para: [hidden email]
> Asunto: [Seaside] Re: Component granularity & numbers
>
>
> "Yanni Chiu" <[hidden email]> wrote
> > The approach will start to break down when the underlying business
> > objects have more specialized behaviour.
>
> If by "specialized behaviors" you mean things that typically
> involve some sequence of user interaction, primarily dealt
> with by WATask or Ajax equivalents, I include these as well.
> I think much of these can be automated by generic components
> + suitable metadata. I'd be interested in other kinds of
> things you consider exceptions as well.
>
> I was looking more for guidance on plain scale of # of
> components. If a page shows 5 primary domain objects in some
> detail, but show another 100 domain objects in summary, some
> of them multiple times (e.g. just their names), should I use
> 105+ components instances or just 5?
>
> Thanks - Sophie
>
>
>
> _______________________________________________
> 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

Yanni Chiu

Re: Component granularity & numbers

In reply to this post by Sophie424

itsme213 wrote:
> I was looking more for guidance on plain scale of # of components. If a page
> shows 5 primary domain objects in some detail, but show another 100 domain
> objects in summary, some of them multiple times (e.g. just their names),
> should I use 105+ components instances or just 5?

I don't see any reason to favour one approach over the other - unless
you're instantiating the 100 domain objects on each response, in which
case the 100 domain objects approach doesn't appear to scale well. (But
the UI interaction may only ever show 100 objects on a page, so no
problem ever arises).

Another problem that might arise is that the 100 domain objects take up
a lot of memory (for whatever reason), but you only really need the
summary description for you UI. So, in this case, a single component
which gathered only the required display data without actually
instantiating the 100 domain objects would seem to be a better approach.

--
Yanni Chiu

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