mynukegenealogy-development Mailing List for MyNukeGenealogy

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

hi,
Any websites running your software? can you give me a link to view?
thanks
Marshall

Martin,

I have to admit, I haven't had a chance to get the latest version 
installed yet.  It looks great on your site though.  I'm pretty excited 
to find time for an install.  My Phd work is really taking alot of time 
right now, but I still plan to free up a little time.  This weekend, I 
will get the latest version installed locally and give some more feedback.

Jeremy

Hi to you all,

You can find on CVS a next release, which I also have included as zip
(without CVS info). I believe, that we are getting
closer to a next "non-beta" release. This version brings you:

	- Handling strongly improved (I hope). It is now easier to enter
new data right in the module.
	- Clearer layout
	- Images support (not very sophisticated, but you can "tag"
images to every individual, family, event, source and note,
              and you can display a "gallery" of all images for a
certain person)
	- Batch uploading of images to a given individual, family,
event, source or note
	- Marking one image as "main" for a given individual, family,
event, source or note, this image is shown on the main screens for the
record
	- Reference/source stuff should work everywhere

It would be great, If some of you would, who have some spare time
somewhen in the next weeks, would invest some of that sparetime
in testing and squeezing the module.

I know of the following shortcomings:

	- MNG may be confused, if you are working in several windows at
once
	- Some export/import problems of objects (images) from/to Gedcom
	- If you are able to get multiple times the same note / image
etc... to one record, the automatic table update routine
  	  was trying to add a unique key to a table where the new unique
key would be violated. In this case, regenerate
	  all tables. This will be fixed.
	- If a list with one entry is displayed, and from this view,
edit commands are used, MNG does not always properly
	  jump back to the original view after editing
	- We are missing "add father", "add mother" commands for a given
individual
	- Layout in certain templates is still not ok.
	- Editing dates is rather complicated. If someone has a good
idea, please tell me!!!
	- Copyright notices and thank-you notices on the MNG-screens are
missing
	- The image routines do not rely on a given gallery module
	- Routines for generating thumbnains are missing (if we use a
module we do not need then), so images
 	  are always displayed in original size, except for the "gallery
view". If you have very big images, tagging
	  these images to e.g. an individual will screw up the display
for that individual

Thanks a lot!!!!

Martin

 <<v051b-alpha-006.zip>>=20

Hi,

I have written a very compact interface layer to PostNuke. For me, the
module runs now with no modifications
(just dropping them onto the PostNuke / PHP Nuke module directories) on
both platforms. I have released
that version as number 050b-alpha-001. I am curiously looking forward to
the reactions!

Martin

Hello all,

I'm here as well.  Hopefully, I will be able to take a look at the CVS 
issue this week.  I'll try really hard to get back up to speed with the 
code.  I'll keep you up to date here on my progress.

Congratulations, Mark, on the new addition to the family.  I can't even 
begin to imagine the amount of work that adds.  Good times, but none the 
less kids always keep you on your toes.  Especially when they are newborn.

Jeremy

Hi Martin et al.

Sorry I've not been around much, my wife went into labour at the start
of project and we've been struggling to keep up normal work and house
alongside babe. Anyway to cut a long tail short, we have a new baby
girl, called Aurian, and she comes and watches me type while listening
to music in the office. 

I've been reading the emails but have not seen anything major to comment
on so have just stayed in the background.

I'm really hoping to get up to date on the work you've all been doing
but my main work is heating up, I've got to go back out to Hong Kong
first week in December and I've got a load of code to prepare for that.

Will try and help in future.

Best Wishes

Mark

-----Original Message-----
From: myn...@li...
[mailto:myn...@li...] On
Behalf Of Martin Rehker
Sent: 27 October 2002 17:52
To: myn...@li...
Subject: AW: [Mynukegenealogy-development] Development

Hi all,

after some more minor modifications and some cleanup, I decided to put
the current state as alpha (explicitly marked ... :-) ) on
www.mynukegenealogy.de 
and on sourceforge.

When I did so with release tagged 042b-alpha-001, the following problem
(already discovered earlier) popped up: I have been inconsistent with
the filenaming (upper/lowercase) in two files in the module root
directory and with the 
directories below /platform. I tried to correct this the usual CVS way:
delete file from repository, rename and check in with new name.
Unfortunately, the 
sourceforge cvs is case insensitive and throws exceptions when you
delete a uppercase file and check it back in as lowercase, as he things,
you "reanimated" the old file. Probably some bug there. After some
fighting with the sourceforge cvs I was able to recover the old files
and to reactivate them. 

Result: If you do not figure out some way to correct the upper/lowercase
mistakes I have made in the mentioned files, we have to live with this.
For the future, we should stay with lowercase file and directorynames.

Btw. What happened to all of you???? Only Jeremy participated in
discussions recently. Are you still alive???????????

Martin

-------------------------------------------------------
This SF.net email is sponsored by: ApacheCon, November 18-21 in Las
Vegas (supported by COMDEX), the only Apache event to be fully supported
by the ASF. http://www.apachecon.com
_______________________________________________
Mynukegenealogy-development mailing list
Myn...@li...
https://lists.sourceforge.net/lists/listinfo/mynukegenealogy-development

Hi all,

after some more minor modifications and some cleanup, I decided to put
the current state as alpha (explicitly marked ... :-) ) on
www.mynukegenealogy.de=20
and on sourceforge.

When I did so with release tagged 042b-alpha-001, the following problem
(already discovered earlier) popped up: I have been inconsistent with
the filenaming (upper/lowercase) in two files in the module root
directory and with the=20
directories below /platform. I tried to correct this the usual CVS way:
delete
file from repository, rename and check in with new name. Unfortunately,
the=20
sourceforge cvs is case insensitive and throws exceptions when you
delete a uppercase file and check it back in as lowercase, as he things,
you "reanimated" the old file. Probably some bug there. After some
fighting with the sourceforge cvs I was able
to recover the old files and to reactivate them.=20

Result: If you do not figure out some way to correct the upper/lowercase
mistakes I have made in the mentioned files, we have to live with this.
For the future, we should stay with lowercase file and directorynames.

Btw. What happened to all of you???? Only Jeremy participated in
discussions recently. Are you still alive???????????

Martin

Hi all,

CVS is moving, quite slowly, but it is moving. I added some more
features, templates and separated
and rewrote the menus for users and admin. Update your CVS, I think some
minor database
change happend also, so recreate your database.

Martin

Ohh, xxxxx ( <- censured )

I did not care that much about case changes, on a Win2k platform
that does not matter. Stupid from me. All lower is fine. We should
make the changes quickly, because they mean deleting a file from CVS
and checking in another one, you cannot rename files / directories
on CVS. And then the history is lost, which I do not really like :-(.

Martin

-----Urspr=FCngliche Nachricht-----
Von: myn...@li...
[mailto:myn...@li...]Im
Auftrag von Jeremy Kroll
Gesendet: Donnerstag, 17. Oktober 2002 16:31
An: myn...@li...
Betreff: Re: AW: [Mynukegenealogy-development] CVS / Multiplatform
support

Hi,

Thanks for the quick bug check Martin.  I looked right at it and didn't=20
recognize the typo.  I noticed there is a bit of case changing in the=20
directories and some of the files.  Are we standardizing on all lower=20
case, or are we mixing?  I prefer all lower case, but it's just my=20
preference.

Jeremy

-------------------------------------------------------
This sf.net email is sponsored by: viaVerio will pay you up to
$1,000 for every account that you consolidate with us.
http://ad.doubleclick.net/clk;4749864;7604308;v?
http://www.viaverio.com/consolidator/osdn.cfm
_______________________________________________
Mynukegenealogy-development mailing list
Myn...@li...
https://lists.sourceforge.net/lists/listinfo/mynukegenealogy-development

Hi,

Thanks for the quick bug check Martin.  I looked right at it and didn't 
recognize the typo.  I noticed there is a bit of case changing in the 
directories and some of the files.  Are we standardizing on all lower 
case, or are we mixing?  I prefer all lower case, but it's just my 
preference.

Jeremy

Hi,

don't worry about me flooding the list with mails. I do it to avoid=20
the situation that someone is working on a outdated CVS copy, especially
with these major changes, we are doing right now.

The initialise.php script should not be called directly, but is=20
called automatically by the index.php and/or admin.php scripts.
The error you mentioning is caused by a stupid bug in the
/platform/select.php
script: I wrote

	require_once("$gepath[platform]/phpnuke/platform.php");

instead of

	require_once("$genpath[platform]/phpnuke/platform.php");

Martin

-----Urspr=FCngliche Nachricht-----
Von: myn...@li...
[mailto:myn...@li...]Im
Auftrag von Jeremy Kroll
Gesendet: Donnerstag, 17. Oktober 2002 11:39
An: myn...@li...
Betreff: Re: [Mynukegenealogy-development] CVS / Multiplatform support

Thanks Martin,

I wish I could be of more help, but my deadline is fast approaching.  I=20
updated my CVS copy and the directory structure looks good.  I can't get

the Initialize function to work in my phpnuke install.  It keeps giving=20
an error "can't open /phpnuke/platform.php".  I'll take a closer look as

soon as I get some time.  I don't have time to work with it today. =20

Jeremy

-------------------------------------------------------
This sf.net email is sponsored by: viaVerio will pay you up to
$1,000 for every account that you consolidate with us.
http://ad.doubleclick.net/clk;4749864;7604308;v?
http://www.viaverio.com/consolidator/osdn.cfm
_______________________________________________
Mynukegenealogy-development mailing list
Myn...@li...
https://lists.sourceforge.net/lists/listinfo/mynukegenealogy-development

Thanks Martin,

I wish I could be of more help, but my deadline is fast approaching.  I 
updated my CVS copy and the directory structure looks good.  I can't get 
the Initialize function to work in my phpnuke install.  It keeps giving 
an error "can't open /phpnuke/platform.php".  I'll take a closer look as 
soon as I get some time.  I don't have time to work with it today.  

Jeremy

Hi all,

again, please update CVS. Do an update of both the module directory
in PHP Nuke and the admin directory - the file /admin/modules/mng.php
changed. Based on our recent discussion I have introduced the platform
framework (subdir platform etc...) in CVS.

Additionally I started with templates for sources and references.

Martin

____________________________________________________
zeb/rolfes.schierenbeck.associates sp. z o.o.
Saski Point * ul. Marszalkowska 111 * PL-00-102 Warszawa
Phone (0048) 22 528 53 51
Fax (0048) 22 528 53 60
EMail mr...@ze... <mailto:mr...@ze...>
WWW www.zeb.pl <http://www.zeb.pl>

This e-mail may contain confidential and/or privileged
information. If you are not the intended recipient (or
have received this e-mail in error) please notify the=20
sender immediately and destroy this e-mail. Any=20
unauthorised copying, disclosure or distribution of=20
the material in this e-mail is strictly forbidden.

Diese E-Mail enth=E4lt vertrauliche und/oder rechtlich=20
gesch=FCtzte Informationen. Wenn Sie nicht der richtige=20
Adressat sind oder diese E-Mail irrt=FCmlich erhalten=20
haben, informieren Sie bitte sofort den Absender und=20
vernichten Sie diese Mail. Das unerlaubte Kopieren=20
sowie die unbefugte Weitergabe dieser Mail ist nicht
gestattet.

Martin,

I was just joking about the long read.   Having a variable naming 
standard would do the trick just as well as encapsulating everything 
within a class.  Strictly using the standard woudl allow us to stay away 
from conflicts.  Some of my professors developed a code naming standard 
years ago.  I'll get a copy and see if it can be applied to mng. 
 Basically, from function and variable naming, we could determine where 
in the code the variable is used.

Jeremy

Hi,

sorry to give you that much to read. I will try to be more concise
the next time :-)

I think, that the solution for the language matter is very easy.
We just rename the functions in the current code. The current module
language handling is independend of PHP Nuke, i.e. not using a specific
PHP Nuke API. So we just need to remove the conflict.

Other issue is the variable separation. This is a good point. My idea
- already realised in most parts of the moduel - is to use variable
names of the form $genxxxxx (e.g. $gen_tables etc.). We could pack
that everything into a class, but a fixed prefix for all MNG variables
may do the same job. What do you think?

I have looked at the ADODB interface. IMHO it should be very easy to=20
pack the ADODB calls into a PHP Nuke-like interface (this way around
will be faster for now ...). If we then make sure, that we have no
variable-name conflicts, the database issue should be solved quickly
as well.

Martin

-----Urspr=FCngliche Nachricht-----
Von: myn...@li...
[mailto:myn...@li...]Im
Auftrag von Jeremy Kroll
Gesendet: Dienstag, 15. Oktober 2002 11:03
An: myn...@li...
Betreff: Re: [Mynukegenealogy-development] Again CVS and proposal for PN
/ PHP Nuke / Standalone integrat

Hi,

That's alot to read through, but from a first read through the structure

looks good.  The platforms directory sounds like a good way to go.  We=20
could get a standalone install working well and then just add the=20
php/post code later.

I have been thinking about some ways to seperate MNG variable from the=20
phpnuke or postnuke global variable.  One problem postnuke has right=20
from the start, is that the language calling function in postnnuke=20
conflicts with the MNG call.  Also, the database calls are a problem for

mysql and postnuke.

I think it would be possible to create a class structure which could=20
make variables and functions MNG only.  Something like mng.getlang().=20
 That way we could seperate all of our calls from anything that the nuke

codes are doing on a global scale.  It would also give us the=20
opportunity to link our mng.xxx() calls and pass them to nuke calls.=20
 The platforms code could act like interpreters.  This carries more=20
overhead, but would probably save us time in the long run.  Let me know=20
whyat you think.  Hopefully, I can dig into this at the end of next
week.

Jeremy

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Mynukegenealogy-development mailing list
Myn...@li...
https://lists.sourceforge.net/lists/listinfo/mynukegenealogy-development

Hi,

That's alot to read through, but from a first read through the structure 
looks good.  The platforms directory sounds like a good way to go.  We 
could get a standalone install working well and then just add the 
php/post code later.

I have been thinking about some ways to seperate MNG variable from the 
phpnuke or postnuke global variable.  One problem postnuke has right 
from the start, is that the language calling function in postnnuke 
conflicts with the MNG call.  Also, the database calls are a problem for 
mysql and postnuke.

I think it would be possible to create a class structure which could 
make variables and functions MNG only.  Something like mng.getlang(). 
 That way we could seperate all of our calls from anything that the nuke 
codes are doing on a global scale.  It would also give us the 
opportunity to link our mng.xxx() calls and pass them to nuke calls. 
 The platforms code could act like interpreters.  This carries more 
overhead, but would probably save us time in the long run.  Let me know 
whyat you think.  Hopefully, I can dig into this at the end of next week.

Jeremy

Hi,

first of all, update your repositories. We now support editing of
family, individual, notes, event, linking and unlinking different
records
to each other. There are still some bugs and the code has to=20
be cleaned up. But if this is done, we are back to the old
functionalities.

Second topic. I propose the following flow and related directory
structure for "multi-plattform" support. Adaption of the code to
certain platforms should be done via selectively including adaptation
code. E.g. we might decide to write an interface from the "old" phpnuke
database calling functions to the "new" postnuke calling functions.
This would be coded into one file.

Directory structure: (/m stands for /htdocs/modules/MyNukegenealogy)

/m/platforms			- 	subdir containing plattform
adapting code
/m/platforms/select.php	-    	script to select the plattform

/m/platforms/phpnuke		-	subdir with phpnuke specific
code
/m/platforms/phpnuke/platform.php=09
					-	script called by
../select.php
						if the phpnuke plattform
is used.=20
						This script should call
all other
						code to use the current
platform
/m/platforms/phpnuke/...	-	any other stuff in
subdirectories

/m/platforms/postnuke		-	subdir with postnuke specific
code
/m/platforms/postnuke/platform.php=09
					-	script called by
../select.php
						if the postnuke platform
is used
/m/platforms/postnuke/...	-	any other stuff in
subdirectories

/m/platforms/standalone		-	subdir with standalone specific
code
/m/platforms/standalone/platform.php=09
					-	script called by
../select.php
						if the standalone
platform is used
/m/platforms/standalone/...	-	any other stuff in
subdirectories

/m/platforms/common/		-	repository for code to be used
						on several platforms
(but not on all).
						E.g. Database interface
code might
						be similar for two
platforms.

In my opinion, code in the "platform" directory should be as
far minimised as possible. In that case, we would not even=20
have to bother about providing several "installations", the select.php
file should just figure out itself. Now to the code-flow, for example in
the
main "index.php" file:

* Startup the module (common startup procedure)
* Load some first minimal common initialisation code
* run /m/platforms/select.php
	This will run the appropriate platform.php file. After
	this step, imho code must not depend on the platform used.
* Check whether database is properly installed (function db_check)
	If not:=20
		If user is admin: Propose to initialise database
		If user is not admin: Warning message and close module
* Load more initialisation code including language stuff
* Go into the main ($do) select statement
* Do some work :-)

I have looked a little bit at the gallery implementation. They manage
to provide the module as PHP Nuke, Postnuke and standalone solution.
I believe, that following their solutions will allow us quickly to=20
have even a standalone version, which would be nice, because it will
at once very much largen the user base.

What do you think about the described structure and flow???

Martin

____________________________________________________
zeb/rolfes.schierenbeck.associates sp. z o.o.
Saski Point * ul. Marszalkowska 111 * PL-00-102 Warszawa
Phone (0048) 22 528 53 51
Fax (0048) 22 528 53 60
EMail mr...@ze... <mailto:mr...@ze...>
WWW www.zeb.pl <http://www.zeb.pl>

This e-mail may contain confidential and/or privileged
information. If you are not the intended recipient (or
have received this e-mail in error) please notify the=20
sender immediately and destroy this e-mail. Any=20
unauthorised copying, disclosure or distribution of=20
the material in this e-mail is strictly forbidden.

Diese E-Mail enth=E4lt vertrauliche und/oder rechtlich=20
gesch=FCtzte Informationen. Wenn Sie nicht der richtige=20
Adressat sind oder diese E-Mail irrt=FCmlich erhalten=20
haben, informieren Sie bitte sofort den Absender und=20
vernichten Sie diese Mail. Das unerlaubte Kopieren=20
sowie die unbefugte Weitergabe dieser Mail ist nicht
gestattet.

Actually, I don't even think we need the dummy pninit and pntables 
files.  I believe if they aren't there, the postnuke modules admin just 
activates the module without creating tables.  So, I'm pretty sure that 
can be struck from the list.  Moving an admin and user gui control php 
file to the upper level directory would be the only thing left.

The main issues I found with the code in postnuke are the language calls 
and the database calls.  After changing those, everything worked fine in 
postnuke 0.6.4.  I haven't tried the code in .721 though.

Jeremy

So, conclusion and to-dos up to now:

1. Move the stuff from the /htdocs/MyNukeGenealogy/admin directory
   one level up (then we have automatically the admin.php file ...).

2. Separate user and real admin stuff

3. Write dummy pntables and pninit

Martin

-----Urspr=FCngliche Nachricht-----
Von: myn...@li...
[mailto:myn...@li...]Im
Auftrag von Jeremy Kroll
Gesendet: Montag, 14. Oktober 2002 11:34
An: myn...@li...
Betreff: Re: AW: [Mynukegenealogy-development] CVS / PN

The pn prefix for files is taken directly from the postnuke module=20
development guide.  If you look at the fully compliant modules they use=20
this naming.  Not a requirement for us though.  I was just showing what=20
a completely compliant module looks like for comparison.

It's easy enough to fake the pninit and pntables.  The postnuke=20
structure has initialize and activate buttons on the module admin menu.=20
 Initialize calls pninit, which uses the table info from pntables to=20
setup your module tables.  pninit could be made to do nothing.

I would say that we currently meet minimum standards.

Jeremy

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Mynukegenealogy-development mailing list
Myn...@li...
https://lists.sourceforge.net/lists/listinfo/mynukegenealogy-development

The pn prefix for files is taken directly from the postnuke module 
development guide.  If you look at the fully compliant modules they use 
this naming.  Not a requirement for us though.  I was just showing what 
a completely compliant module looks like for comparison.

It's easy enough to fake the pninit and pntables.  The postnuke 
structure has initialize and activate buttons on the module admin menu. 
 Initialize calls pninit, which uses the table info from pntables to 
setup your module tables.  pninit could be made to do nothing.

I would say that we currently meet minimum standards.

Jeremy

Hi,

the directory structure described, and some of the comments
you made is related to modules which strongly use the PN api.
E.g. the table creation etc. is all done by PN for modules using it.
I would for now try to avoid using that, we would be fixed to PN
only. Rather, I was interested in the "minimum" requirements.
That does not mean, that I do not like the PN API...

From what you wrote, I understand that we have the following
minimum requirements:

1. all code contained in one top-level directory
2. separation of user / admin stuff
3. Some code to setup the tables and modules (pntables, pninit)

1. I believe, that we already fulfill 1. Quite a while ago, I replaced
all code in the /htdocs/admin/... directories with simple
"include-links"
to files in the /htdocs/modules/MyNukeGenealogy/admin directory, so that
for=20
PN you would just ignore the content of the /htdocs/admin directory.

2: Most of the stuff which is currently called via the "admin" interface
actually should become user stuff (e.g. editing data, reading
gedcom files), protected by appropriate access rights. We almost have
no real admin stuff (except dropping and recreating the tables ...), as
a configuration module is not yet written :-(. If you agree, we=20
should step by step try to move the "user" stuff out of the
"admin" index.php to the "user" index.php. We can do this, it will
be rather really easy.

3: Are these two files the core requirement for PN? If yes, it is
possible to fake a pntables (no tables), leave the table-generation
stuff where it is and write a pninit? What is supposed to be in the
pninit???

Do we have other requirements????

Martin

-----Urspr=FCngliche Nachricht-----
Von: myn...@li...
[mailto:myn...@li...]Im
Auftrag von Michael Swinarski
Gesendet: Montag, 14. Oktober 2002 05:42
An: myn...@li...
Betreff: Re: [Mynukegenealogy-development] CVS / PN

None of the modules that I have use the 'PN' prefix on the filenames...

But other then that, looks pretty much like it.
-m

> Hi,
>=20
> Here is a quick description of a postnuke module.  I could send you
the
>  entire module development guide, which is 224KB.  Let me know if you=20
> want a copy.  The basics are as follows:
> modules/
>     example_module/
>         pnadmin.php
>         pnadminapi.php
>         pnblocks/
>             example_block.php
>         pnimages/
>            example_image.png
>         pninit.php
>         pnlang/
>             deu/
>                 admin.php
>                 init.php
>                 manual.html
>                 example_block.php
>                 user.php
>             eng/
>                 admin.php
>                 init.php
>                 manual.html
>                 example_block.php
>                 user.php
>         pntables.php
>         pnuser.php
>         pnuserapi.php
>         pnversion.php
>=20
> Well that's the general directory structure.  pntables describes the=20
> table structure and pninit generates the tables from pntables and sets

> up the module in postnuke.  The rest is relatively self explanatory.=20
>  Other directories and files are allowed within a module, but this is=20
> considered a minimum.  I think the seperation of the I/O of the user
> and  admin interfaces will be a requirement for portablility.
>=20
> Jeremy
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Mynukegenealogy-development mailing list
> Myn...@li...
>
https://lists.sourceforge.net/lists/listinfo/mynukegenealogy-development

--=20
Michael Swinarski

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Mynukegenealogy-development mailing list
Myn...@li...
https://lists.sourceforge.net/lists/listinfo/mynukegenealogy-development

None of the modules that I have use the 'PN' prefix on the filenames...  
But other then that, looks pretty much like it.
-m

> Hi,
> 
> Here is a quick description of a postnuke module.  I could send you the
>  entire module development guide, which is 224KB.  Let me know if you 
> want a copy.  The basics are as follows:
> modules/
>     example_module/
>         pnadmin.php
>         pnadminapi.php
>         pnblocks/
>             example_block.php
>         pnimages/
>            example_image.png
>         pninit.php
>         pnlang/
>             deu/
>                 admin.php
>                 init.php
>                 manual.html
>                 example_block.php
>                 user.php
>             eng/
>                 admin.php
>                 init.php
>                 manual.html
>                 example_block.php
>                 user.php
>         pntables.php
>         pnuser.php
>         pnuserapi.php
>         pnversion.php
> 
> Well that's the general directory structure.  pntables describes the 
> table structure and pninit generates the tables from pntables and sets 
> up the module in postnuke.  The rest is relatively self explanatory. 
>  Other directories and files are allowed within a module, but this is 
> considered a minimum.  I think the seperation of the I/O of the user
> and  admin interfaces will be a requirement for portablility.
> 
> Jeremy
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Mynukegenealogy-development mailing list
> Myn...@li...
> https://lists.sourceforge.net/lists/listinfo/mynukegenealogy-development

-- 
Michael Swinarski

So what I said in the last mail was a long way of saying that I think 
the current directory structure works well.  Postnuke's main requirement 
is that everything be contained in a single high level directory.

Jeremy

Hi,

Here is a quick description of a postnuke module.  I could send you the 
entire module development guide, which is 224KB.  Let me know if you 
want a copy.  The basics are as follows:
modules/
    example_module/
        pnadmin.php
        pnadminapi.php
        pnblocks/
            example_block.php
        pnimages/
           example_image.png
        pninit.php
        pnlang/
            deu/
                admin.php
                init.php
                manual.html
                example_block.php
                user.php
            eng/
                admin.php
                init.php
                manual.html
                example_block.php
                user.php
        pntables.php
        pnuser.php
        pnuserapi.php
        pnversion.php

Well that's the general directory structure.  pntables describes the 
table structure and pninit generates the tables from pntables and sets 
up the module in postnuke.  The rest is relatively self explanatory. 
 Other directories and files are allowed within a module, but this is 
considered a minimum.  I think the seperation of the I/O of the user and 
admin interfaces will be a requirement for portablility.

Jeremy

Hi,

some more changes to CVS. Please update and recreate your databases. We
can now
add and link childs. We are very close to the functionalities of 032b
:-).=20

I have the following question / comment: CVS is terribly messy about
changing
directory structures. Could we now find the target directory structure,
which is supported
by all PN, PHP-Nuke and Standalone? Actually, I need to know, what you
consider important
in terms of PN directory structure. What is your proposal?=20

And please, let's change directories in CVS only after we have agreed on
a proposal.

Martin

2002	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (33)	Sep	Oct (37)	Nov (3)	Dec
2003	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep (1)	Oct	Nov	Dec
2010	Jan (1)	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

mynukegenealogy-development Mailing List for MyNukeGenealogy

mynukegenealogy-development — Developer list