On 22 April 2018 at 15:48, Jan Iversen <jancasacon...@gmail.com> wrote: > > >> On 22 Apr 2018, at 16:41, sebb <seb...@gmail.com> wrote: >> >> On 22 April 2018 at 14:53, <j...@apache.org <mailto:j...@apache.org>> wrote: >>> Hi >>> >>> Looking at the latest emails, it seems like a compromise between the 2 >>> solutions are the best solution. >>> >>> How about if the combine the proposals to the following (that would make my >>> life easier, and hopefully satisfy the majority of problems Sebb see). >>> >>> >>> Based on site-json I propose the following changes: >>> >>> Change docs/scripts/attic.js to project.json (kept as pure json outside >>> docs). >>> Remove xdocs. >>> >>> Allow a build job to monitor for svn changes and if any active a generation >>> script. >>> >>> The generation script does the following: >>> - generate a sidebar.inc which is included (physically in all files) >> >> Not sure how you mean the inclusion to work. >> Do you mean a server-side include? That increases the load on the >> server, but Infra may agree to it. >> Or would the project.md template be processed to include the contents? > > Sorry for not being clear, yes project.md should automatically include it if > possible, otherwise the generator.sh should write it. We want the site to be > totally static. >
OK, so there will need to be a generator script to take the template and apply each section of the data file to it. I don't think it makes sense to design a new templating system, so I think we need to use an existing one. Do you still object to using Jekyll? >> >>> - Generate a page pr. project in projects, based on a 1 template >>> “project.md” or similar >> >> What would convert project.md into projects/project.html? > generate.sh or something similar. >> >> What about the additional data that is present in many of the XML files? >> Where would that be stored? > I suggest to use “description” or add a second field “additional” in JSON, > both solutions are OK with me. Description is not suitable for all the data. >> It's really awkward to put it in projects.json. > > For me, only touching1 file is the highest importance in a new maintenance > model, apart from that, you talk about history, this has not happened for a > very long time, so it is a onetime effort. I still don't understand why it is so important to have all the project data in a single file. I agree that one should not have to edit two different files to record the data for a single project, but I don't see what the problem is with having a single file for each project. There would still only be a single file to edit, but it would be a different file for each project. >> >>> - Generate a flagged directory (if field “flag” is present in the JSON >>> object”) >> >> OK. >> >>> This solves all URL issues, the concern about JS, all redirection issues as >>> far as I can see…and (to me) importantly maintenance is updating >>> projects.json and nothing more (related to the site). >>> >>> How do you all feel about this compromise ? >> >> I think it is closer, but it does not cover the requirement to >> preserve the existing additional data in the XML files. > > Yes, either in “description” (one time effort, even though e.x. taglibs > require some editing) or in an additional field (same work). In either case, adding more than a few words of text to a JSON value is hard work, especially if there are HTML tags and quotes involved. Any subsequent maintenance is hard (e.g. to correct spelling etc.) It is similar to editing compressed CSS. We should not be creating unmaintainable data files. > I can guarantee as long as I am the maintener there will not be additional > projects with this feature, mainly because that information should already be > available on the respective HP. The information is generally not on the home page because it is not relevant to an active project. It is only after the project retires that the additional information may need to be provided. > rgds > Jan I >> >>> rgds >>> Jan I. >>> >>> Ps. I can help to change attic.js, but I am afraid the generate script is >>> for someone else to write. >
