Please correct me if I am incorrect in my understanding of a few things:
1) If all of the stand-alone pieces or sub-parts of NarWeb and will only be used to create web pages, then what is the purpose for needing and using HtmlDoc? Gerald already created libhtml.py to parse through the created pages and write them out to XHtml...
2) If there is to be parts to NarWeb for every piece of the objects, then there will be a lot of pieces... Why separate Places and Maps as they are essentially part of each other? If a user doesn't want to create Maps for places then don't run that class...
3) I LOVE the idea that each sub part will have its own options for that object! Here is what I would like to see for the options section of NarWeb...
** Have a two vertical panes window:
a) Left pane shows the different object types ( Person, Families, Places, Events, Sources, Notes, Media, Repositories). When the user clicks on the object,
b) it will show its options in the right pane. Including a linked menu option, which could have something like: "Include Places in your report?" Once selected the options for places beomes activated...
c) Before the users starts selecting object types that he/ she wants to be included, there are the basic options which affect the base of WebSite Report...
4) Create one style sheet with all of the basic elements that is selected and copied into its directory no matter which style sheet is selected for the website! Have a directory structure for each different styles heet within Gramps, with having individual elements for each object that is selected. The individual object type elements will override the basic set of elements that are within the base style sheet... I believe that this is possible right now within the style sheets as they are currently! With something like the Ancestor Tree, leave it as one sheet as it is now...
a) The individual object types style elements could be in a read-only file and WebSite Report reads the style elements and creates one style with the individual pieces for each object...
I guess that this is all that I have right now!
Rob G. Healey
Forgot referenced webpage for UUID discussion:
 - http://www.gramps-project.org/wiki/index.php?title=GEPS_009:_Import_Export_Merge#UID.2C_GUID_and_UID.2C_what_is_needed_in_GRAMPS.3F
On Tue, Nov 23, 2010 at 11:35 AM, Doug Blank <email@example.com> wrote:
> On Tue, Nov 23, 2010 at 11:10 AM, Gerald Britton
> <firstname.lastname@example.org> wrote:
>>>> 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.
>> Note that NarWeb today is already two-pass (through the data). On the
>> first pass, it builds a list of the handles to report on, invoking the
>> various filters along the way. The list is then sorted by name, IIRC.
>> On the second pass, it builds the pages. So, are you really talking
>> about three passes then?
> Well, it isn't exactly, strictly two pass... some things get built as
> they are processed. What I'm doing is separating the passes
> completely, so that on the second pass on these "pools" should be
> treated as read-only. Also, each component will get a chance to add to
> the pool on the first pass, before any processing is started. Then the
> pools are not passed around to only what needs them, but are available
> through the main WebSite Report object (where all shared items go).
>>>> 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
>>>> 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.
>> Is handle the correct mapping? The thing is, if you backup your
>> database, then reload it, you will get new handles. If you then try
>> to regenerate your website in the same place, you will have
>> duplication and/or collisions. Perhaps this is why others have asked
>> for a built-in UUID which would provide a permanent "handle". For
>> that matter, we could use UUIDs instead of the handles currently
>> generated on the fly for the bsddb primary keys (futures idea).
> You are absolutely correct that the UUID will be a map to a unique,
> consistent filename. But we don't have that yet. The discussion on
> that topic is linked to at . UUIDs will involve more than just
> longer handles, as we need to keep track of a set of them for each
> object, as we discover other items that refer to (or are the same as)
> the primary UUID.
> But for Gramps 3.3, I am assuming that we won't have UUIDs in place
> yet, and so WebSite will be largely be a drop-in replacement for
> NarrWeb and will keep the same filenames. BTW, you won't get new
> handles, unless you go through something other than Gramps XML.... it
> preserves the handles.
>>>>> 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.
>>>>> Gramps-devel mailing list
>>> 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.
>>> Gramps-devel mailing list
>> Gerald Britton
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.
Gramps-devel mailing list