Angus Leeming <[EMAIL PROTECTED]> writes:
| 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.
this is the exception (external data), for all internal stuff
serialization _and_ the mailer stuff are really overkill.
| 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.
And I am not so sure that this is a good idea at all... we shouldn't
expose external structures like this, and if/when we recieve them from
external we _must_ do validation anyway....
in-lyx we do not have to do validation of data since we know that we
made them in the first place.
>> - 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.
Which are really just doing just the same ... call it
poor-man-serialization if you want.
--
Lgb
