I am playing now with this script. Nice work but I noticed some things that I think should change.
* Smarty templating system to easy the design of the site,
I noticed that the avarage script page takes about 25-30 seconds to open for someone with dialup. Most of the javascripts eat your browsers memore after browsing the script for a while.
I usually template without tables in CSS. I am creating my own template now, by removing most of the tables in e.g. header and footer files I managed already to take of 5 seconds increasing the loading time of the page and usuability for all browsers.
My question is, do the developers intend to use Smarty and drop the PHP Nuke like system. Smarty can also cache the templates.
Also, I am using CSS <ul> tags for dynamic menu's. How can I drop the current javamenu's and use my own optimised one?
Other question, if I finish the template is anyone interested?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Smarty templates are overkill and are way too complex for the simplicity they try to add. We develop based on the KISS (Keep-It-Simple-Stupid) principle.
I never had to wait 30 secs to open a page on dial up on an old 300MHz machine. You should check if the performance change is realized at the server or at the browser client. You can check server side performance by turning on the execution statistics in the gedcom configuration.
When you talk about tables you are really talking about client side performance. This depends on the connection speed, the machine it is running on and how much available memory there is. It also depends on the browser's cache. Some of the themes are slower loading up than others.
We spend a lot of time designing the site and the supported themes to make them work well in all of the languages and in RTL. Our experience is that tables work better for RTL languages.
In general, caching the templates is a bad idea in PGV because you don't want any privacy information to be cached. Any information that is cached, must be cached in a format that can then be filtered for privacy.
You can change the menus by changing the toplinks.html file in the themes directories. If you want to change the programming at the PHP level, then you can modify the print_menu() function in the functions_print.php.
We are in the process of redesigning the architecture of PGV to make it easier to change the HTML output without doing so much PHP programming but it will be a gradual process that occurs over the next several versions.
--John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thnx for the quick reply.
I tried and tested on my localhost. Especially the newer browsers show the time like that.
Wouldnt be caching an option restricting the directory for caching with a .htacces file? Just thinking out loud here. Smarty isn't that complex, of the demo sites that I saw on the site 9-10 use standard templates. Also I think you'd agree that reducing the script size also narrows the bandwidth usage. I just read the article that was posted by a reviewer on your site and it also states that societies can use it. Our society plans to use it, but in case of a lot of users your bandwidth goes out the door ;-)
To come back to Smarty. I dont know if you are familiar with Phorum.org. They use a decent system of templating that allows users to do a lot by just adjusting the header.tpl, footer.tpl and css file. The other files can be used for the more professional designers. Also, I do see a lot of pro's for tpl files. Mainly that the script becomes more flexible.
Also I see some languages that haven't been translated. Would you be interested in more?
You didnt reply to my question on a new template. I can make CSS compliant templates as well with tables if necesarry. What do you have on the todo list for newer versions? Maybe I can contribute.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, so I presume no one is interested in my contributions.
I will pass this then to our board of directors, I see little use that our society uses this script then, we will check the GNU possibilities but I think we will end up creating our own system then.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Without sounding like a jerk..... 2 posts, twice mentioned I wanted to contribute and no response on those points. So due to the lack of enthousiasm its only fair to assume that there is no interest into contributions such as templates and other tweaks I just discovered..
I am looking at this script but also on 2 alternatives at the moment with 3 other societies. I understand this is your project and I am a newcomer, but I am not a n00b. However if I were you I would clean up the code due to XSS etc. At the current moment I dont think this script can handle the amount of users we have.
But anyways before I make myself look like a schlemiel. Good luck on the project, if you ever decide to use tpl files for templating I am interested, I might as well just further develope this script that way. I will see what is best and what our societies want to spend etc. etc.
Again, no hard feelings and good luck with your script.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do you have a specific XSS (or other based on the etc you mentioned) problem with the code that you would care to share? People do this as a hobey and the lack of response especially on a weekend when there is usually little to no traffic should not indicate any rejection. Is there something specific you would like to contribute? As mentioned earlier, a move to Smarty is out of the question now.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I will freely admit that PGV is not perfectly designed for templating and I believe that we can build a better more scalable architecture designed to meet the specific needs of genealogy, but still be flexible enough that the layout can be easily changed. Over the next few iterations we will be moving PGV to a more object oriented, MVC architecture. You can see the beginnings of this by looking at the new individual.php and family.php pages in the future branch of the CVS. http://cvs.sourceforge.net/viewcvs.py/phpgedview/phpGedView/individual.php?rev=1.252.2.119&only_with_tag=future&view=auto
This new architecture will allow you to completely change the individual page to your liking without having to hardly touch PHP code.
Whatever templating system is used, I still think that 8 out of the 10 implementations will continue to use the standard themes provided as is the case in almost any web based project. Most people don't want to open and edit files, and that is why the standard themes are used. (How many people would change their desktop background if they had to edit a text file to do it? Same reasons why Linux has not caught on as a desktop replacement for Windows.) We have experimented in the past with an online theme/CSS editor, but it looked to be a maintenance nightmare and eat up too much of our precious development resources.
Of course we want more people to help in the development of the project... we are an Open Source project built on the foundation of people freely contributing their unique talents. But there has to also be some control. In the past we have just allowed everyone who wanted onto the development team. This has caused problems, mostly management problems trying to keep track of what everyone is working on. Many developers have come on excited to help out, and then they discover that they don't have as much time as they need to really stay involved and so they go inactive leaving code half finished and leaving bugs un-fixed for the rest of us to sort out. I've been meaning to post the criteria for becoming a PGV developer on the website, but it will have to wait until we update the website for v3.4. Basically, we want to make sure that a developer is committed to the project and is willing to sacrifice the time that it takes. We would like to see them involved in the community helping users and maybe fixing a bug or submitting a patch first. For those people who don't have a lot of time they can regularly contribute to the project, but who still want to help, I usually recommend that they work with the CVS files and submit their work as patches. Then they can be involved, but without the pressure of being on the development team.
Yes, we are interested in more translations. We are especially looking for people who are willing to help maintain translations through future versions. We just recently received a Vietnamese translation and a new Danish translation.
The open items on this list are items that still need to be finished for version 3.4. Most of the open items are close to being completed... which means we are close to releasing the 3.4 beta. The pending items in the list are already in place in the future branch. There are also the Bugs and Future branch bug trackers that we need to work on.
We don't have a roadmap for features beyond the next version. But it includes items in RFE tracker of which there are ~200. We can't do all of them all at once, but we try to do what we can. Some of the general ideas that have come up in development conversations are enhancing the web services and data linking, object oriented architecture, mapping and place metadata, and research assistance to name a few.
I hope this answers most of your questions.
What specific requirements do you have for your site? Maybe we can help you in deciding if PGV will meet those requirements. How many users do you anticipate? (The most I have seen is around 400 and at that level user management starts to be an issue.) How many individuals do you plan to have in the database? Do you have hardware/software requirements? How many hits/day do you anticipate?
--John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am playing now with this script. Nice work but I noticed some things that I think should change.
* Smarty templating system to easy the design of the site,
I noticed that the avarage script page takes about 25-30 seconds to open for someone with dialup. Most of the javascripts eat your browsers memore after browsing the script for a while.
I usually template without tables in CSS. I am creating my own template now, by removing most of the tables in e.g. header and footer files I managed already to take of 5 seconds increasing the loading time of the page and usuability for all browsers.
My question is, do the developers intend to use Smarty and drop the PHP Nuke like system. Smarty can also cache the templates.
Also, I am using CSS <ul> tags for dynamic menu's. How can I drop the current javamenu's and use my own optimised one?
Other question, if I finish the template is anyone interested?
Smarty templates are overkill and are way too complex for the simplicity they try to add. We develop based on the KISS (Keep-It-Simple-Stupid) principle.
I never had to wait 30 secs to open a page on dial up on an old 300MHz machine. You should check if the performance change is realized at the server or at the browser client. You can check server side performance by turning on the execution statistics in the gedcom configuration.
When you talk about tables you are really talking about client side performance. This depends on the connection speed, the machine it is running on and how much available memory there is. It also depends on the browser's cache. Some of the themes are slower loading up than others.
We spend a lot of time designing the site and the supported themes to make them work well in all of the languages and in RTL. Our experience is that tables work better for RTL languages.
In general, caching the templates is a bad idea in PGV because you don't want any privacy information to be cached. Any information that is cached, must be cached in a format that can then be filtered for privacy.
You can change the menus by changing the toplinks.html file in the themes directories. If you want to change the programming at the PHP level, then you can modify the print_menu() function in the functions_print.php.
We are in the process of redesigning the architecture of PGV to make it easier to change the HTML output without doing so much PHP programming but it will be a gradual process that occurs over the next several versions.
--John
In this case, KISS stands for Keep-It-Simple-Smarty :-)
Hi,
Thnx for the quick reply.
I tried and tested on my localhost. Especially the newer browsers show the time like that.
Wouldnt be caching an option restricting the directory for caching with a .htacces file? Just thinking out loud here. Smarty isn't that complex, of the demo sites that I saw on the site 9-10 use standard templates. Also I think you'd agree that reducing the script size also narrows the bandwidth usage. I just read the article that was posted by a reviewer on your site and it also states that societies can use it. Our society plans to use it, but in case of a lot of users your bandwidth goes out the door ;-)
To come back to Smarty. I dont know if you are familiar with Phorum.org. They use a decent system of templating that allows users to do a lot by just adjusting the header.tpl, footer.tpl and css file. The other files can be used for the more professional designers. Also, I do see a lot of pro's for tpl files. Mainly that the script becomes more flexible.
Also I see some languages that haven't been translated. Would you be interested in more?
You didnt reply to my question on a new template. I can make CSS compliant templates as well with tables if necesarry. What do you have on the todo list for newer versions? Maybe I can contribute.
Ok, so I presume no one is interested in my contributions.
I will pass this then to our board of directors, I see little use that our society uses this script then, we will check the GNU possibilities but I think we will end up creating our own system then.
Why do you presume that?
Without sounding like a jerk..... 2 posts, twice mentioned I wanted to contribute and no response on those points. So due to the lack of enthousiasm its only fair to assume that there is no interest into contributions such as templates and other tweaks I just discovered..
I am looking at this script but also on 2 alternatives at the moment with 3 other societies. I understand this is your project and I am a newcomer, but I am not a n00b. However if I were you I would clean up the code due to XSS etc. At the current moment I dont think this script can handle the amount of users we have.
But anyways before I make myself look like a schlemiel. Good luck on the project, if you ever decide to use tpl files for templating I am interested, I might as well just further develope this script that way. I will see what is best and what our societies want to spend etc. etc.
Again, no hard feelings and good luck with your script.
Do you have a specific XSS (or other based on the etc you mentioned) problem with the code that you would care to share? People do this as a hobey and the lack of response especially on a weekend when there is usually little to no traffic should not indicate any rejection. Is there something specific you would like to contribute? As mentioned earlier, a move to Smarty is out of the question now.
Many people have wanted more control over the presentation of the pages, and Smarty has come up before. You can see a recent conversation about this here:
https://sourceforge.net/tracker/index.php?func=detail&aid=1234551&group_id=55456&atid=477082
I will freely admit that PGV is not perfectly designed for templating and I believe that we can build a better more scalable architecture designed to meet the specific needs of genealogy, but still be flexible enough that the layout can be easily changed. Over the next few iterations we will be moving PGV to a more object oriented, MVC architecture. You can see the beginnings of this by looking at the new individual.php and family.php pages in the future branch of the CVS.
http://cvs.sourceforge.net/viewcvs.py/phpgedview/phpGedView/individual.php?rev=1.252.2.119&only_with_tag=future&view=auto
This new architecture will allow you to completely change the individual page to your liking without having to hardly touch PHP code.
Whatever templating system is used, I still think that 8 out of the 10 implementations will continue to use the standard themes provided as is the case in almost any web based project. Most people don't want to open and edit files, and that is why the standard themes are used. (How many people would change their desktop background if they had to edit a text file to do it? Same reasons why Linux has not caught on as a desktop replacement for Windows.) We have experimented in the past with an online theme/CSS editor, but it looked to be a maintenance nightmare and eat up too much of our precious development resources.
Of course we want more people to help in the development of the project... we are an Open Source project built on the foundation of people freely contributing their unique talents. But there has to also be some control. In the past we have just allowed everyone who wanted onto the development team. This has caused problems, mostly management problems trying to keep track of what everyone is working on. Many developers have come on excited to help out, and then they discover that they don't have as much time as they need to really stay involved and so they go inactive leaving code half finished and leaving bugs un-fixed for the rest of us to sort out. I've been meaning to post the criteria for becoming a PGV developer on the website, but it will have to wait until we update the website for v3.4. Basically, we want to make sure that a developer is committed to the project and is willing to sacrifice the time that it takes. We would like to see them involved in the community helping users and maybe fixing a bug or submitting a patch first. For those people who don't have a lot of time they can regularly contribute to the project, but who still want to help, I usually recommend that they work with the CVS files and submit their work as patches. Then they can be involved, but without the pressure of being on the development team.
Yes, we are interested in more translations. We are especially looking for people who are willing to help maintain translations through future versions. We just recently received a Vietnamese translation and a new Danish translation.
The todo list for newer versions begins with the version 3.4 tracker located here:
https://sourceforge.net/tracker/?atid=704879&group_id=55456&func=browse
The open items on this list are items that still need to be finished for version 3.4. Most of the open items are close to being completed... which means we are close to releasing the 3.4 beta. The pending items in the list are already in place in the future branch. There are also the Bugs and Future branch bug trackers that we need to work on.
We don't have a roadmap for features beyond the next version. But it includes items in RFE tracker of which there are ~200. We can't do all of them all at once, but we try to do what we can. Some of the general ideas that have come up in development conversations are enhancing the web services and data linking, object oriented architecture, mapping and place metadata, and research assistance to name a few.
I hope this answers most of your questions.
What specific requirements do you have for your site? Maybe we can help you in deciding if PGV will meet those requirements. How many users do you anticipate? (The most I have seen is around 400 and at that level user management starts to be an issue.) How many individuals do you plan to have in the database? Do you have hardware/software requirements? How many hits/day do you anticipate?
--John