On Tue, 2002-07-23 at 16:19, Aleksei Valikov wrote:
>
> Now I understand - this is clearly my design fault. I've checked the
> documentation once again. The misuse is that our components also store data.
> There is, for instance, document editor, which stores document that the user
> edits. That is, our components are stateful. What are the recommendations to
> deal with data?
Is it possible to abstract the data out of your components without a
complete rewrite, i.e. make document editor into a flyweight[1] class?
The point being that all of the data is stored under one API (one or
more classes) and the document editor is rewritten to access the data
using that API.
The primary advantage is that your data is now loosely coupled from
document editor. Meaning you can save state without worrying about how
Avalon re-instantiates document editor. A few other potential benefits
of abstracting the data are:
+ decrease your memory load (less code duplication)
+ allow pooling of document editors (memory and cpu cycles)
+ decrease maintenance costs
+ decrease learning curve (for other programmers :)
Not being familiar with your app I don't know how big of a project this
would be, but I'm guessing it'd probably be well worth it, especially if
you're committed to Avalon at this point.
Corey
[1] Design Patterns, Erich Gamma et al
http://www.amazon.com/exec/obidos/ASIN/0201633612/qid=1027445791/sr=2-1/ref=sr_2_1/002-8569892-4366422
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
