> >I am not really talking about this in connection with the visual editing > >part. Livedocs was developed initially to fulfill this need. A translator > >needed to wait a lot of time to get a new generated version of the XML... > >A lot of people are unable to imagine how that XML will look like in > >HTML... > > erm, so you want something like a WYSIWYG tool ? It could be cool if we > find a way to ./build.sh only_this_file
As I have said, livedocs was started for this reason. There is no need to run build.sh if you modify some files (just in case you added sections, entities, etc.). It is still very fast to run, and I doubt we could make it faster for building only one file... > >The idea is to build the livedocs files on the rsync server and let down > >the files with rsync to the mirror sites. As I have described in a > >previous letter, how could all the languages be built by the same time is > >an interesting question, since builds share the same files > >(file-entities.ent, and stuff). > > If the build is done on the rsync server, then the rsync server will > have two CVS checkouts (livedocs and phpdoc-all). > The administrator will cvs up both of them and then configure with the > phpweb line and finally run the build. > > The CVS checkouts will not be rsynced directly, will simply rsync the > $OUTPUT_DIR content to the mirrors. I am not quite sure you understand what we have come up with and fixed in the linuxtag summary. It is important that every step should be automated, and that mirrors should not be changed significantly. As it seems currently, only the sqlite extension need to be installed on mirrors to make livedocs work (as long as we could do the other required things programatically). We have came up with something like this: rsync.php.net checkes out phpdoc-all and zendAPI and livedocs and configures every language in livedocs (which in turn configures phpdoc too). This creates all the needed files, so those should be moved to rsync space, and let the mirrors rsync the new files. This way, mirrors will have an actual copy of livedocs and the actual XML files. If the cache files are also in rsync space on the mirrors, then the current suggested rsync setup will flush the cache the same time the mirror sysncs, and the cache will start building again from the new XML and livedocs files. The tricky part is that the currently commonly used files should have langauge dependent names (like file-entities-it.ent, file-entities-de.ent), so phpdoc could be configured the same time for all languages... Livedocs need to be aware of this, when selecting a language (maybe having manual-it.xml and manual-de.xml, or letting livedocs choose the entity files depending on the language)... The question of validity was also raised. If an XML checkout is not valid, then the update process running on rsync should leave the old version of that language in place, and should not update the XML files for that language. In case of the English version if not valid, then most of the languages will not be valid... > >I am not sure yet :) I would better move the 'theme' parts out of > >livedocs first. I have for example, that HTML headers and footers are > >emitted at multiple places in the source files, and this makes harder to > >see what is happening... > > As we need to fix the issue with the php.net manual first, I'm preparing > a patch that will do the following : > > - adds a --with-theme=THEME_NAME to configure. This value will default > to the "phpweb" theme. > - substitute @THEMENAME@ in config.php.in to define a PHP constant > called THEME_NAME > > For the moment, I will only introduce this constant to define $css_url > this way : > > -$css_url = WEBBASE . CSSURL; > +$css_url = WEBBASE . 'themes/' . THEME_NAME . '/' . CSSURL; > > and to include the headers and footers definitions (I'll group them in a > file and move it to skins/phpweb/) > > Are you ok with this ? Yes. Goba
