> I see, I'm bringing traffic into this mailing list. Just give me a hint,
> when I will start to be boring. :)
that'll be lack of response.
> I just want to point out that we are now discussing an example of the
> component - the document editor. Initially I was introducing a more abstract
> framework for building complete web applications from sets of components.
hmm. But when you get confused and talk high level design, examples make
it so much easier on the brain =)
> > > 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.
>
> Document I am talking about is pure DOM document. Document editor already
> changes/manages it through an API, DOM API, so actually nearly no rewrite is
> needed. But what exactly do I do with the document instance?
what you don't do is make it a component! It seems to me that what you'd
probably want to do is put it in the Context you pass to your document
editor.
> Of course, it
> is possible to extract document-related data from the document editor. But
> where do I store it?
=)
Inside a "Store" component I'd say. We've got a few things like it. You
probably want something like
interface editor
{
contextualize ( Context ); // contains initial document
start(); // get ready for editing
performEdit( Action ); // modify document
doBlah(); // do you stuff
Node getDocument(); // get document
stop(); // we're done with you!
}
interface docmanager
{
compose( cm ); // reference to pool of editors, and a store
Node getdocument( key );
editor geteditor();
releaseeditor( editor );
savedocument( node );
}
interface store
{
Object load( key );
save( key, value );
}
the document is not a property of the editor; nor is session management
of concern to the editor.
> This is my question. I'm new to Avalon and the question
> is: if components should be stateless, then how application state is saved?
> Speaking about web applications, state information may be stored in a
> session and components somehow gain access to it. Is this the preferred way
> I should follow?
for now, session management you'd probably want to do outside your
"container". Whenever you restore a session, you create a new - what do
you call it again - "model" instance and provide it with session data.
Your model can then create Contexts, Configurations etc for your
components based on the session data.
> > 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.
>
> We're not afraid of development, you know. But I (personally) need deeper
> knowledge of Avalon to avoid faulty design. The question about data storage
> is right now very interesting. :)
you sound eager to learn....you'll be fine =)
cheers,
- Leo
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
