Sent from my iPad
> On 23 Apr 2018, at 00:29, sebb <seb...@gmail.com> wrote: > >> 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. ack. > > Do you still object to using Jekyll? no, that is a tool, and does in reality no affect my way of work. > >>> >>>> - 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. I highly disagree, because this is only historic data fro a few sites. So even though it might be messy. it does not matter, because it is a one-time translation. > >>> 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. > Due to several reasons: - a single file is edited/committed, multiple files is created/edited/committed. - Multiple files allow for different project layouts, making it a lot more difficult to change layout in the future. - 3rd party who want to read our data will be more complicated (due to format e.g. md but also different layout so parsing the md file will be challenging. > 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. you tend to forget this file has to be created. > >>> >>>> - 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. Look at svn log, to see how often these files have changed, never, and again it is a thing of the past so it will never change. It is very sure, we never used that in the near history, and will surely not miss it in the future. I for one are not prepared to accept a more complicated solution, due to some very old, not maintained, files. In my mind nobody would notice if we simple cut the information (reading sone of the files, it seems the information is already very outdated, e.g. they point to other dead projects). I do however accept your point of keeping the information, abd the solution is there. > >> 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. > Well it is not in our charter to provide better information than the project did, that is why the wast majority of pages do not have and will not get this information. It seems you think it is a feature for the future, but it is not, so let us try to look at the demands for the future. while being able to solve the past, with a one-time effort. rgds jan i >> 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. >>
