Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | Andre Poenitz wrote:
>>> Have you considered changing that params2string interface to
> | ...
>>> (or when we are at it even
>>>
>>> ostream & InsetBranchMailer::operator<<(ostream & os,
>>> InsetBranchParams const &)
>>> {
>>> os << name << ' ';
>>> os << name_ << ' ';
>>> params.write(os);
>>> // Add all_branches parameter to data:
>>> os << params.branchlist.allBranches() << "\n";
>>> return os;
>>> }
>>>
>>> one concept less to grasp and even better re-usable...)
>>
> | Let's think about this a little more, and let's illustrate this
> | with examples of the code in use in the core.
>
> Do we really have to make this even more complex?
We were just discussing alternatives. This one got ditched quite
quickly. If you were to look at the mailer code now, you'll find it
is becoming quite straightforward. Have a look at the end of
insetcommand.C.
> Notes:
>
> - boost::any is almost an perfect fit here
No it's not. If the data is passed as a string then we allow the
outside world to receive the data, modify it and post it back with no
addditional effort to us.
I'm imagining a scheme where pybliographer could register as a
"replacement citation dialog". Thereafter, clicking on the inset
would send the data to Dialogs::show("citation", data, inset) as now,
but the data would be posted out through the LyX server (or socket).
pybliographer would modify this data and post it back.
> - serilizatoin is added to boost soon
This is certainly a possiblility, but we already have read and write
functions for all insets / most parameter structs. By using those, we
have a self-documented format that is guaranteed to be up-to-date.
> - probably could we even use xtl (oh well)
André argued at the time that this was overkill for what we needed.
The read/write methods are what we need.
--
Angus
