Jump to content

Martin

NewMembers
  • Content count

    5
  • Joined

  • Last visited

Community Reputation

0 Neutral
  1. Well, I knew someone would do a better job of explaining the differences, and it is no surprise that it is John Cardinal. I agree with almost everything you said, John, including your comment that it would be a disservice to declare dynamic sites a "clear winner" - I tried not to do that, or to oversimplify the differences, just to indicate what my personal preferences are, and not claim that dynamic sites are "a good choice for 'all' users". This preference is based on what I want the site to do, and that will of course differ among Web site owners. But I did try to simplify things a bit, because it is pretty complicated and this forum isn't the place to get into all the issues - users will have their work cut out for them if they want to dig into this topic. One comment of John's I would like to expand on is that dynamic sites require greater expertise - they do. Not because of the program itself, it is the server side requirements that can get complicated. And security is a big issue, which with the present state of the art requires a lot of work on the site owner's part. Lastly, John, I think it is terrific you plan to develop a dynamic site program. I am sure it will be a superior product, and I will be very interested in evaluating it for my own site. Martin
  2. Dick, to be honest, I think I was subconciously hoping you wouldn't ask the question. It is a very simple concept, but it is not so easy to explain in a way that immediately makes the differences between static and dynamic Web sites obvious. Depending on content, they can look and act very much the same. But I googled "static vs. dynamic Web sites" and found I am not the only one who has trouble explaining it, so I don't feel too bad. So I'll try an example. Say I have a modestly sized genealogical database on TMG (which happens to be the case). I can use a program like Second Site (which I did purchase) to create a Web site from this database which I can then publish on the Web. Subsequently I get new information which updates several families and exhibits. I enter the data in TMG, then use SS to create new Web pages, which I then upload. A user then can see the updated data on the newly updated pages. That's the "static" scenario. Or in the "dynamic" scenario, I upload the new data directly, using my browser, into a database already in place on the Web server, and when the user requests information, the new data is automatically included in the page the user sees, because the page is created when the user requests it. The advantages are pretty clear- I have fewer steps to go through, and I don't have to track which pages need to be updated or uploaded. With a large site that can be quite onerous. And although I don't use this functionality for genealogy data, just for exhibits and links, it also means database development can be collaborative and on-line. In my case (and as recommended by the TNG author), I do use a separate database "at home" - TMG6 - for reasons given in my earlier post. But I still don't have to create updated pages and upload them- all I have to do is export a GEDCOM and upload it and new media, which is a lot quicker, and easier to track for maintenance purposes. I realize GEDCOM output is limited, and others may prefer to include more information in their online genealogical presentations, so this solution won't work for everyone, but to me the flexibility far outweighs this disadvantage. Hmm, clear as mud, I'm afraid, and long-winded to boot. Hope it helps some, though. I would be glad to give a few more examples via email if you would like, but you have probably had more than enough of this already... Martin
  3. Terry, The short answer is yes, these dynamic sites, at least the php-MySQL based type, can be searched by search engines. Optimizing the site for search engine bots can take a little work, but that is true for most sites, really. And you're right, if that functionality were not present, it would hardly be worth using this approach. BTW, I took a look at the program "Regau" noted (TNGv.5) - very similar to PhpGedView in its capabilities, very nice implementation of the idea. Also compatible with content management systems. And I was interested to note that the author also suggests using a desktop (i.e., local, for most users) program as the main repository, pretty much for the same reasons I alluded to. For those unsure about the difference between static and dynamic pages, looking at some of the sample sites on the TNG site, or at www.phpgedview.net, might help them to understand the difference. Martin
  4. Helge, My solution to this may not fit your needs but here it is: I use TMG6 for exactly the reason you note - accuracy (and completeness), but for my Web site I use phpGedView in a Joomla environment. This gives me, and my users/visitors the power and convenience of a DB driven tool in their browser, while I can maintain a more complete DB locally. If anyone requests additional info on sources etc., I can readily supply it (if I have it...). PhpGedView makes uploading gedcoms and media trivial, and the Joomla environment means I can easily add a lot more that is hopefully of interest to site visitors (newsfeeds, links, library, etc.). After using a dynamic Web tool I would never go back to static pages (like those generated by Second Site). BTW, if you do "roll your own" let us know! Martin
  5. Violettes of Virginia I tried Second Site but was not satisfied with the results. My first try used a basic HTML generator, but site is now (January '06) completely revised with a Content Management System (Joomla) with many componenets (library, forum, guestbook, RSS feeds - completely updatable by the Admin through a Web interface). PhpGedView is completely interactive, presenting the user with a completely functional online genealogy program. Users can maintain their own accounts, download all or part of the GEDCOM, and use internal messaging to communicate with each other. TMG6 remains the core DB program because of its completeness, with exported GEDCOMS uploaded to the Web site as needed, which phpGedView does internally, no ftp required.
×