Menu
▾
▴
Re: [Gramps-devel] GEPS 022: Narrative Website Refactor
|
From: Doug B. <dou...@gm...> - 2010-11-23 14:58:15
|
On Tue, Nov 23, 2010 at 9:09 AM, Benny Malengier <ben...@gm...> wrote: > > > 2010/11/23 Doug Blank <dou...@gm...> >> >> I've been studying and hacking on NarrWeb for a while in an attempt to >> understand the best way forward. I've just created a GEPS outlining >> the proposed changes [1]. Comments welcomed here, or on the GEP. >> >> -Doug >> >> [1] - >> http://www.gramps-project.org/wiki/index.php?title=GEPS_022:_Narrative_Website_Refactor >> >> This page documents a proposal to refactor Narrative Website into more >> manageable parts, and to create a more solid foundation going forward. >> >> Narrative Website >> >> Issues: >> 1. Narrative Website (NarrWeb) is a very popular Gramps report among >> Gramps users >> 2. NarrWeb perhaps has more reported bugs and issues than any other >> component of Gramps >> 3. NarrWeb should give a complete and accurate rendering in a web >> browser, which has many complexities >> 4. The size and complexity of the NarrWeb code has grown considerably >> since its initial version >> 5. People consistently want NarrWeb to do even more >> 6. NarrWeb is now monolithic and has many interacting, brittle parts >> 7. There are needs for new features (such as object linking from >> notes) that require changes in NarrWeb >> 8. There is a need for a way of connecting other web reports (such as >> WebCal) onto NarrWeb >> 9. It would be good to create parts that can be re-used in Gramps Connect >> >> Because of these issues, a refactor is proposed. The main goals are: >> >> 1. Break NarrWeb into manageable parts, each of which can be tested, >> refined, and replaced >> 2. Move the complex, standard parts into a core that doesn't change as >> much, separate from more dynamic code >> 3. Move to a two-pass, component driven process >> 4. Reuse the Report plugin infrastructure for sub-components >> >> Proposal Details >> >> The main goal of the refactor is to move each major part of NarrWeb >> into its own Web Report that can be run as a stand-along webreport, or >> as a sub-report of the refactored NarrWeb. >> >> The refactored NarrWeb shall be referred to as WebSite, and can >> incorporate any other Web Report into a comprehensive web site. >> >> For example, all of the following would be independent Web Report plugins: >> >> * Homepage >> * Person List >> * Place List >> * Family List >> * Download >> * Note List >> * Calendar >> >> Because these reports can be run stand-alone (ie, not from WebSite) >> they can be tested independently. >> >> In addition, third-parties can create additional Web Reports that can >> be included to be run stand-alone or as an integrated page from >> WebSite. >> >> Website will contain all of the common functions needed when reports >> are run together. There may need to be a library for common functions >> when reports are run standalone. >> >> Users will select what sub web reports they wish to include. (It would >> be very handy here to have "named settings" for creating different >> kinds of websites. However, this is a Feature Request that others have >> asked for for other plugins as well, and is not covered here.) >> >> When as user selects a sub web report for inclusion, a Options Page >> will appear. Users can then set the options for the sub web report. >> >> Each sub report will be responsible for the following: >> >> * Collect its own data (but stored in a common place) >> * Handle its own options >> * Create its own pages >> >> Perhaps the same WebSite options will be necessary for each sub report >> when running the sub report in stand-alone mode. >> >> Other Issues >> >> It has been noted that NarrWeb currently uses some non-standard >> functions, and does not fully use the HTMLDoc Backend. These types of >> issues will be more fully addressed after the refactor. > > I think one of the main issues is the filename issue. Yes, that is definitely something that I had in mind, and why I mentioned the two-pass change. I think of it as the "included item issue" because we need to know whether a link should be made, or not, to a referenced item. > In my mind, the Website should hold a pool, and the parts must link to that > pool to do stuff. A first pass can be done to build up the pool, after which > one after the other report can do it's stuff. Yes, I'm thinking that each sub report will be responsible the first pass, data collection phase (in your words, in will contribute to the pool). > Eg: > > PersonLists part wants to write out a list page and individual people > pages. The pool registers this. Extra is that this part als registers > requests for other pages, eg source or place pages that it would like to > link to. > The MapPart is a plugin the user downloaded from gramps-addons that adds a > map to indiv people with the event places. It registers with the pool, > together with the css file shipped with it. There might be some order dependencies here. The MapPart plugin should run after the PlaceList plugin, so that it knows what places have been referenced. At first I was thinking of a two-level plugin system: all of the Lists being one level, and then report(s) to handle each individual object as a second level (like PlacePart and MapPart). Perhaps we need some way to indicate that distinction... > The Website after the first pass starts to write pages. First it sets up the > header, then the PersonList adds it's div elements for the indiv person > page, the Website then passes this to the MapPart plugin which adds it's div > sections, after which the Website adds the required footer section. > > Note that in above the indiv person part adds links to sources. For this, it > checks the pool first if the source will actually be written out, so as to > only do a link when the source is present. This point is related to an option I have in the newer Proxy interface. What if you want to create a website that has all of the *referenced* objects, regardless of whether that object is included in the proxy? There wasn't a way to spider over all of the objects, pulling in all referenced objects. Of course, you can avoid this by including everything, but if you use a proxy, there wasn't an easy way to get, say, a person mentioned in some source. There is a new proxy called referencedbyselection that has a flag called all_people, but I haven't enabled it. If it is False, then it will spider over the objects, adding people to the proxy as it goes. > So, in this scheme, the website pool holds the filenames that will actually > be written. Right. I was just thinking of it as the handles, but there needs to be a mapping from handle to filename. Thanks! -Doug > Benny > >> >> >> ------------------------------------------------------------------------------ >> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! >> Tap into the largest installed PC base & get more eyes on your game by >> optimizing for Intel(R) Graphics Technology. Get started today with the >> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. >> http://p.sf.net/sfu/intelisp-dev2dev >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel > > |