Quantcast

GEPS 022: Narrative Website Refactor

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

GEPS 022: Narrative Website Refactor

DS Blank
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.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GEPS 022: Narrative Website Refactor

Benny Malengier


2010/11/23 Doug Blank <[hidden email]>
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.
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.
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.

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.

So, in this scheme, the website pool holds the filenames that will actually be written.

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GEPS 022: Narrative Website Refactor

DS Blank
On Tue, Nov 23, 2010 at 9:09 AM, Benny Malengier
<[hidden email]> wrote:

>
>
> 2010/11/23 Doug Blank <[hidden email]>
>>
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GEPS 022: Narrative Website Refactor

Gerald Britton-2
[snip]
>> 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?

>
>> 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.

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).

>
> 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
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>
>>
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>



--
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.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GEPS 022: Narrative Website Refactor

DS Blank
On Tue, Nov 23, 2010 at 11:10 AM, Gerald Britton
<[hidden email]> wrote:

> [snip]
>>> 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
>> 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.
>
> 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 [2]. 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.

-Doug

>>
>> 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
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>
>
>
>
> --
> 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.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GEPS 022: Narrative Website Refactor

DS Blank
Forgot referenced webpage for UUID discussion:

[2] - 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

-Doug

On Tue, Nov 23, 2010 at 11:35 AM, Doug Blank <[hidden email]> wrote:

> On Tue, Nov 23, 2010 at 11:10 AM, Gerald Britton
> <[hidden email]> wrote:
>> [snip]
>>>> 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
>>> 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.
>>
>> 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 [2]. 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.
>
> -Doug
>
>>>
>>> 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
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>>>
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>>
>>
>>
>>
>> --
>> 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.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GEPS 022: Narrative Website Refactor

robhealey1
Greetings:

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!

Sincerely yours,
Rob G. Healey



On Tue, Nov 23, 2010 at 8:36 AM, Doug Blank <[hidden email]> wrote:
Forgot referenced webpage for UUID discussion:

[2] - 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

-Doug

On Tue, Nov 23, 2010 at 11:35 AM, Doug Blank <[hidden email]> wrote:
> On Tue, Nov 23, 2010 at 11:10 AM, Gerald Britton
> <[hidden email]> wrote:
>> [snip]
>>>> 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
>>> 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.
>>
>> 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 [2]. 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.
>
> -Doug
>
>>>
>>> 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
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>>>
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>>
>>
>>
>>
>> --
>> 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.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GEPS 022: Narrative Website Refactor

DS Blank
On Tue, Nov 23, 2010 at 5:23 PM, Rob Healey <[hidden email]> wrote:
> Greetings:
>
> 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...

There was a request to attempt to unify some things between the two
HTML gen systems, but as I mentioned, I'm not working on that level of
refactor.

But, it might be possible to include text reports using the HTMLDoc
backend. For example, it could be possible to have a link of of each
person's page to a statically created HTML text report.

> 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...

We'll have to break them up into pieces that make sense. The idea is
that if next year someone comes with a new and improved Map Report, it
could be easily included on each Place Page.

> 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...

Well, that's just Object Oriented Programming design :)

> ** 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!

Thanks! Some good ideas here!

-Doug

> Sincerely yours,
> Rob G. Healey
>
>
>
> On Tue, Nov 23, 2010 at 8:36 AM, Doug Blank <[hidden email]> wrote:
>>
>> Forgot referenced webpage for UUID discussion:
>>
>> [2] -
>> 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
>>
>> -Doug
>>
>> On Tue, Nov 23, 2010 at 11:35 AM, Doug Blank <[hidden email]> wrote:
>> > On Tue, Nov 23, 2010 at 11:10 AM, Gerald Britton
>> > <[hidden email]> wrote:
>> >> [snip]
>> >>>> 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
>> >>> 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.
>> >>
>> >> 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 [2]. 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.
>> >
>> > -Doug
>> >
>> >>>
>> >>> 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
>> >>>>> [hidden email]
>> >>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>> ------------------------------------------------------------------------------
>> >>> 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
>> >>> [hidden email]
>> >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> 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.
>> http://p.sf.net/sfu/intelisp-dev2dev
>> _______________________________________________
>> Gramps-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GEPS 022: Narrative Website Refactor

Benny Malengier


2010/11/24 Doug Blank <[hidden email]>
On Tue, Nov 23, 2010 at 5:23 PM, Rob Healey <[hidden email]> wrote:
> Greetings:
>
> 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...

There was a request to attempt to unify some things between the two
HTML gen systems, but as I mentioned, I'm not working on that level of
refactor.

But, it might be possible to include text reports using the HTMLDoc
backend. For example, it could be possible to have a link of of each
person's page to a statically created HTML text report.


Just to put the dot's on the i, HtmlDoc is the html implementation of our textreport doc backend. There is no reason for narweb to use that.
HtmlDoc uses libhtml, which narweb uses also. However, HtmlDoc does this via htmlbackend, which contains some functions that narweb might need or might want to extend (eg links in notes would be done by the backend, but then we need a way to know the page to link to).

So, the overlap is only in some specific functions. As the aim is different, some overlap probably cannot be avoided. The complicated stuff should be done only once though, which specifically means eg styled notes.

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Loading...