[Seaside] List views style question

[Julian Fitzell]

Hi Steven,

Good question.

Assuming ProposalView is a subclass of WAComponent, you don't really want to
be using the same instance repeatedly with different data. This will prevent
state backtracking from working properly, because the state is
saved/restored at the beginning/end of the request processing.

If ProposalView doesn't have state, it likely doesn't need to be a component
at all (you could subclass from WAPresenter in Seaside 3.0 or just create
your own class) but even then you probably want to use a new instance each
time.

The array approach is a good one and it allows you to return the array in
your #children method (which you should be doing for all sub-components).
But you may run into the problem that the array gets out of date with the
current list of proposals.

Probably the best option is to use a Dictionary (or possibly a
WeakDictionary) to map Proposals to ProposalViews. You could implement
#children like so:

children
  ^ Proposal proposals collect: [ :ea | proposalViews at: ea ifAbsentPut: [
ProposalView new proposal: each; yourself ] ]

Then you can iterate over the proposals in your render method but look up
the correct view in the dictionary.

Julian

On Sat, May 1, 2010 at 9:50 AM, Steven Baker <steven at stevenrbaker.com>wrote:

> Heya folks,
>
> I have a small style question. At least, I think it's a style question.
>
> Consider a ProposalListView which has a single instance variable
> proposalView, which is an instance of ProposalView. ProposalView has a
> proposal: accessor. I currently have a small number of proposals (less than
> 5 at a time) so I do the following:
>
> ProposalListView renderContentOn: html
>        html heading: 'Proposals'.
>        Proposal proposals do: [ :each | html render: (proposalView with:
> each) ].
>
> This works to display all of my proposals, but I can't help but feel that I
> should be pre-populating an array of ProposalViews ahead of time for
> rendering. I have a gut feeling that tells me I should instead have a
> proposalViews instance variable containing an array of the views, like so:
>
> PoposalListView initialize
>        super initialize.
>        proposalViews := Array new.
>        Proposal proposals do: [ :each | proposalViews add: ProposalView new
> proposal: each ]
>
> (I've written the code above to simplify the idea; please forgive any
> errors.)
>
> Is there a technical reason why my code should be written in one way or the
> other? Perhaps I'm missing the point entirely, and I should be writing this
> completely differently?
>
> Thanks,
>
> -Steven
>
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20100501/a8c9fb0a/attachment.htm