[geeklog-devel] Geeklog 2.2.0 - What do we want?

Wim Niemans niemans at nlbox.com
Sat Sep 13 19:10:03 EDT 2014


Tom, all,

like most of you, I don’t have an ocean of time too. I try to get around, though.

It is quite easy to have glPage in a 100% compatible mode. That is, the theme should create their  specific layout. But that should be a one liner. For themes that adhere to the GL standard, there is even not a change.

To have glPage as I intent to, there is a lot of work to do. The themes could be the road block here. As I understand something will be done on css-class naming and probably also on id-naming. This is very important because templates will be involved too. Having a template-lookup mechanism as announced (only changed files in a theme-dir) is very, very helpful.
Having said that, the work to adjust the core-functions (all functions that return html in some way) is easy but heavy. And it can be done in a compatible way. The result is much, much more flexible.

My roadmap is (1) to deliver a testing module, that runs in cli. So interested developers can test or evaluate the glPage and family easily on the command line. Second will be making inventory of css-class names and adjust them with a standard rule (which is not yet available). Third is producing a demo with the most important functions (COM_ and ADMIN_) adjusted. After that I don’t have more steps, or better, I don’t define the sequence of next steps. That’s up to you.

My plugin is running smooth with the principle, but in a different naming convention and in a advanced form. So for now I just have to strip the advanced methods and rebuild the testing system.

But today I am off for a week of holidays. I hope there will be reactions when coming home. .-)

Cheers,
Wim


On 13 Sep 2014, at 15:48, Tom <websitemaster at cogeco.net> wrote:

> Hi Wim,
> 
> Part of the problem of the lack of replies is 2 of the other main developers
> replying (who contributed a fair bit to the last release) is that I believe
> they are pretty busy at the moment (like myself). They also are from Japan
> so communication can be an issue as well. 
> 
> In a forum post you mention incorporating the glpage class into a plugin. I
> am wondering if we should give you write access to our repository. This way
> you can create a new branch and incorporate it directly into Geeklog and
> covert Geeklog, core plugins and themes as you go. This will allow the rest
> of us to test things as needed (or contribute when we can). Once everything
> is working we can then merge it back into the main branch.
> 
> The glPage class will be a lot of work (along with the conversion of Geeklog
> and keeping backwards compatibility) and if you plan to put all this thought
> and work into it I don't want it to go to waste (as I am sure you don't).
> Plus we are always looking for new developers who want to contribute
> (http://wiki.geeklog.net/index.php/Coding_Guidelines).
> 
> How does this sound to everyone? 
> 
> Do you have any input Dirk?
> 
> What are your thoughts on this idea Wim?
> 
> Thanks
> 
> Tom
> 
> 
> -----Original Message-----
> From: geeklog-devel [mailto:geeklog-devel-bounces at lists.geeklog.net] On
> Behalf Of Tom
> Sent: September-10-14 5:35 PM
> To: 'Geeklog Development'
> Subject: Re: [geeklog-devel] Geeklog 2.2.0 - What do we want?
> 
> Since the conversation started in the forum (and the thread is a few pages
> long) any replies specifically about the glpage class I think should be kept
> in the forum.
> 
> Thanks
> 
> Tom
> 
> -----Original Message-----
> From: geeklog-devel [mailto:geeklog-devel-bounces at lists.geeklog.net] On
> Behalf Of Wim Niemans
> Sent: September-10-14 9:23 AM
> To: Geeklog Development
> Subject: Re: [geeklog-devel] Geeklog 2.2.0 - What do we want?
> 
> 
> Besides Tom and Ben, no developers are seen at the forum to disclose their
> opinions. Either there is no interest, either everybody is quite happy with
> current GL rendering functions.
> Maybe the forum is not the right place to discuss, maybe the abstraction
> level is not good.
> Maybe other reasons?
> 
> https://www.geeklog.net/forum/viewtopic.php?showtopic=95800
> http://wiki.geeklog.net/index.php/Wireframes
> http://wiki.geeklog.net/index.php/GlPage
> 
> Background of the effort: I've developed a plugin (still in the works)
> inspired by the forms plugin and databox by Ivy. My experiment uses graph
> notations for database access and 'paints' in a canvas object using a faces
> concept (similar to glPage). This works quite well, bug free and loads fast.
> The plugin contains more OO-classes that could be of interest: exceptions,
> (db)lexicon, maps, validators. For now I am working to deliver glPage and
> associates with 100% compatibility. It would be very sour if it turns out
> that it will not make it into the core.
> 
> Wim
> 
> 
> On 31 Aug 2014, at 17:50, Tom <websitemaster at cogeco.net> wrote:
> 
>> For those interested on a discussion on the new page class please 
>> check out the Geeklog Forum
>> 
>> https://www.geeklog.net/forum/viewtopic.php?showtopic=95800
>> 
>> Tom
>> 
>> -----Original Message-----
>> From: geeklog-devel [mailto:geeklog-devel-bounces at lists.geeklog.net]
>> On Behalf Of Tom
>> Sent: August-23-14 10:50 AM
>> To: 'Geeklog Development'
>> Subject: [geeklog-devel] Geeklog 2.2.0 - What do we want?
>> 
>> Hi All,
>> 
>> Here is a list of items that I see as important and I would like to 
>> see tackled in the next version of Geeklog. This doesn't mean that 
>> everything is going to make it but I want to reach out to the 
>> community to
> get your ideas.
>> 
>> For those of you interested in possibly helping out let us know which
>> item(s) you are hoping to work on. Also if you have any features you 
>> would like to possibly add to Geeklog let us know.
>> 
>> The things I plan on tackling first would be the OAuth stuff and the 
>> Page Class.
>> 
>> 1. Update OAuth Library
>> 	- Add page to wiki showing how to make it easier for other
> developers
>> 	- We should this for other outside libraries we use (file manager, 
>> jquery, editors, etc...) 2. Remove MSSQL and/or PGSQL Support 3.
>> Update CK Editor 3. Fix Bugs
>> 	- Fix not support browser for CK Editor (#0001753)
>> 	- etc...
>> 4. Update Geeklog.net 
>> 	- Use Downloads Plugin
>> 	- Developers Page
>> 5. XMLSitemap Plugin - Add dedicated API (#0001757) 6. Create Page 
>> Class (combining it with COM_createHTMLDocument)
>> 	- Add Pagination with rel="next" and rel="prev"
>> 	- Depreciate COM_siteHeader, COM_siteFooter
>> 	- COM_createHTMLDocument would still be available for backwards 
>> compatiblity 7. OAuth Users to the submission queue (#0001736) 8.
>> Multiple Topics in Search (#0001670) 9. Drop support for LDAP and Live 
>> Journal authentication. OpenID?
>> 10. Demo Site option (#1059)
>> 11. HTML 5 theme
>> 
>> 12. Integrate GSOC Calendar project (Ben??) 13. Plugin Repository GSOC 
>> project
>> 
>> Thanks
>> 
>> Tom
>> 
>> _______________________________________________
>> geeklog-devel mailing list
>> geeklog-devel at lists.geeklog.net
>> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>> 
>> _______________________________________________
>> geeklog-devel mailing list
>> geeklog-devel at lists.geeklog.net
>> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>> 
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
> 




More information about the geeklog-devel mailing list