On Fri, Sep 28, 2012 at 3:13 PM, Benny Malengier
> 2012/9/28 Tim Lyons <guy.linton@...>
>> Benny Malengier wrote
>> > We urgently need a new maintainer for this plugin. If anybody is
>> > interested
>> > in the job, don't hesitate to step forward.
>> Benny, I am looking at Narrative Web. After all, I only started coding
>> Gramps because I wanted to make a tiny change to one of the pages on Nar
>> I'm not too sure about restructuring it.
>> If I had two passes, would it be best to implement them as two classes
>> (class IndividualPagePass1 and IndividualPagePass2) or as functions within
>> one class? Anyone got any examples of what it might look like?
> I never worked in the nar web, which is why I also am not keen to dive in.
> Doug has normally a good grasp of the internals, as he had ideas to
> restructure it.
> I think most bug tickets and the 4 problems as given above, can be fixed
> with little change to the current structure.
> To keep nar web maintainable, something more drastic, like splitting the
> code over different files, use templates of some kind instead of only div
> element classes you have to look up in the code to know which are what,
> reuse of gramps-connect settings, and some heavy reuse of code via functions
> (Rob was not good at that, having learned python only recently by trial and
> error) seems like the way forward. I would need to know the code however to
> be able to make suggestions.
I'd be glad to work with Tim and help advise (have already provided
some hints about what I would do given unlimited resources). Here is
* Use the new Export Selection Options (somehow). Currently, these are
not "Options" and so can't be integrated into the Options for saving
and loading from the config files.
* Make a two-pass Narrative web, so we know exactly what things will
be included in the website.
* Don't create links to objects not included in the website.
* Break each section (Person, Family, Media, etc) into a mini-report.
Then the code could be broken up into loadable/configurable options. I
imagine that there could be plugins for each section, which could be
included/not on running.
* Refactor the code so to break up HTML/CSS from the code. Currently
webdesigner-types have a hard time changing the output because the
code dictates too much HTML/CSS structure.
>> View this message in context:
>> Sent from the GRAMPS - User mailing list archive at Nabble.com.
>> Got visibility?
>> Most devs has no idea what their production app looks like.
>> Find out how fast your code is with AppDynamics Lite.
>> Gramps-users mailing list