[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ML] Hosting of gnustep.org

From: H. Nikolaus Schaller
Subject: Re: [ML] Hosting of gnustep.org
Date: Tue, 19 Jan 2021 13:57:15 +0100

> Am 19.01.2021 um 13:42 schrieb David Chisnall <gnustep@theravensnest.org>:
> On 19/01/2021 12:12, H. Nikolaus Schaller wrote:
>> How would all this work for dynamic content 
>> likehttp://www.gnustep.org/softwareindex/  ?
> Can you be a bit more specific?  At first glance, that looks pretty static: 
> There's a top-level index page and a load of child pages.  I'd put each of 
> the entries in a Markdown file with the metadata in the YAML frontmatter.  
> Jekyll can load that as a collection, sort and index it, and generate the 
> main page and each sub page from templates.  Each of the sub-indexes 
> (Application, Developer Tool) and so on is just the top-level index filtered 
> by things that match some key in the metadata.
> The only dynamic thing that seems to work is the search box.

Yes. An the filter (it is not used but part of the tool).

>  Given that this is searching from under a hundred things, all of which can 
> be downloaded in a single HTTP request quite cheaply, you could do that 
> client side in less than one network round trip time.

And you can click the "Anything wrong with this entry? Click here to fix it!" 
button at the end of the page allowing to propose new version or add screen 
shots. Tell me how that should work.

>> How can you make pages that can be sorted/filtered dynamically on 
>> user-request?
> Normally, with client-side JavaScript.

What is your norm?

>  I realise that some people dislike JavaScript, but in 2021 I think that 
> battle is probably lost.

No I don't dislike it at all - but why do a new solution if one exists?

> There are off-the-shelf JavaScript things for sortable / filterable / 
> searchable tables, I quite like this one, which gives you a single .js file 
> and falls back to a non-sortable table gracefully if JavaScript is disabled:
> http://www.kryogenix.org/code/browser/sorttable/

Yes, I know - but why choose a new solution if one exists? 
> I don't seem to be able to sort the table with the live version and the 
> filter by OS and Model boxes let me filter by Any, with no other options in 
> the drop-down.

Yes, that is because there is only a single category for these values.

> Making the filter box work on the summary table is pretty trivial, just 
> iterate over the table entries, hide (set the hidden property in the DOM) any 
> table rows that don't match the search term.

That is exactly what the SQL select behind is also doing.

> Using a database or any server-side scripting seems massively overengineered 
> for this.

No, it is not over engineered. It is already done! And is standard technology. 
Look for example at Joomla, MediaWiki, NextCloud etc. They all do the same. 
Some mix it with JavaScript to make some user interactions smoother.

>  If the software index grows to have thousands of entries, I'd change my 
> mind, but the complete data for the summary table is likely to be a couple of 
> K and so you're likely to need more network traffic for boilerplate on 
> multiple page requests with the same template than you save by filtering the 
> contents on the server.

That may be true, but is even a counter-argument against your ideas: if it is 
just some K (hence not wasting resources), why do a complete rewrite of it (not 
to forget debugging) a working solution? This would waste other resources, i.e. 
developer's time.

>> How can you make a page with user-generated change requests send out an 
>> e-mail to reviewers for approval?
> I wouldn't.  Folks that want to update it can raise a GitHub PR that has 
> their new Markdown file in it.  They can install the github-pages Ruby Gem 
> and run jekyll-serve locally to test how their changes will look before 
> submitting.  GitHub automatically sends emails about PRs to all maintainers 
> of a project.
> I've seen this scale to projects with hundreds of contributors, I don't 
> imagine GNUstep having problems with it.  Looking at that index, it appears 
> as if it averages less than one update per month currently.

Ok, I see you want to invent something completely new instead of thinking about 
how to easily move the existing.
In my experience, such proposals will rarely be completed because it is 
possible to use the new technology, but it takes far more time than simply 
continuing to use the old.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]