Jean-Marc Lasgouttes ha scritto:
Basically, the main stated plan for the 1.6 branch is switching our
file format to some correctly formed xml. There is already some
proof-of-concept code to do that in a branch. This will force us to
have a more unified way to access the parameters, and I was arguing
that we could _maybe_ leverage this for dialog/kernel interaction.
Many thanx for the explanations to everybody.
From what I understood, it seems
there is no actual reason for having inside LyX xml-based
or string-based interactions among MVC components,
if it is possible to have (model's typed) object-based interactions.
For example, when view event handlers activate controllers,
these may perform direct invokations of the model functionality
through using direct parameters passing. Actually, in order to
preserve the possibility of catching the functionality dispatch
request in multiple points of the code, it is useful to have a
base FuncRequest class encapsulating any type of request.
IMHO, such class (or a related one e.g. FuncParams) could be
subclassed by various functionality in order to add to the
structure as many params as needed by the single functionality.
Somewhere else, the dispatching code will retrieve those params
from such structure and activate the functionality through the
model-API specifically created for it.
Example:
[in the model]
find(docstring string_to_find, bool casesensitive, bool whatever);
[in the dispatching framework]
class FuncRequestFind : public FuncRequest {
public:
FuncRequestFind(..., string_to_find, bool casesensitive, bool whatever);
docstring string_to_find;
bool casesensitive;
bool whatever;
virtual void dispatch() {
find(this->string_to_find, this->casesensitive, this->whatever);
}
}
[in the controller]
SearchController::onFindNext() {
docstring string_to_find;
bool casesensitive;
bool whatever;
request_dispatch_of(new FuncRequestFind(..., string_to_find,
casesensitive, whatever);
}
This would avoid the unnecessary overhead of serializing/deserializing
these parameters all the time. Despite the simple find example, if the
number of params grows or if they are numeric, or just if the parser
wants to be very sure about syntax for robustness purposes (e.g.
parsing from the command-buffer or from the command-line, we don't
want segfault if the user types a wrong syntax), parsing
them may become heavy. I can't even imagine having an xml-writer and
an xml-parser and validator being activated for each and every key press
or button press while using LyX.
In addition, the possibility of having string-based or xml-based
serialization/deserialization of these parameters and the existence
of a FuncRequest dispatching mechanism adds the possibility
to invoke such functionalities *also* by other means, for example:
- from the command buffer
- from an external script
- from a remote client
All you need, in this case, is to add a standard
serialization/deserialization
mechanism to the base FuncRequest class, and override the serialization
methods in the subclasses, e.g.
FuncRequestFind::serialize(iostream & s) { // maybe XMLIOStream &
parent::serialize(s);
s.serialize(string_to_find);
s.serialize(casesensitive);
s.serialize(whatever);
}
This is just to stress that I hope the model will not start exporting
only functions that take a serialized form of params. That would be
too bad (imho) -- unless I'm missing smth.
T.
