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

Wim Niemans niemans at nlbox.com
Tue Sep 30 18:53:11 EDT 2014 

Had a pretty good trip and really nice weathers.

Taking into account the few reactions I’ve seen and had, I’ve decided as Tom did propose. This means that my roadmap must change and integration can be targeted at GL3. In this case a smooth transition is helpful and instead of a testing/evaluation module there will be a plugin delivered soon that is compatible with GL2.x. This plugin can be used to adjust current plugins since adjustment is pretty minimal. 
However the real problem is located in the current themes (I’m at my original step 2: inventory of classes en ID’s). I realise that glPage is dependent on the themes to have success. So I intend to deliver with the plugin a adjusted theme, which is the real work. Doing that, I need some information:

1. it seems that quite a lot classes identify already with the prefix ‘gl-‘ (which is necessary to allow for css-frameworks). What’s the status of that work? What about the classnames in PEAR? Will this be finished before GL3?
2. There are COM_functions (and probably others too) that generate the attribute ‘id=…’; the places I’ve found are in terrible error to do so. Best example is COM_getTooltip. Can this be considered as bugs, or is the consensus to let it be?
3. In glPage there exist the possibility to repeat blocks (layouts). Best example is a pagination component that can be placed BEFORE the list-layout and AFTER the list-layout, simply by settings. Since layouts have a name in glPage, this name is used to makeup the id in the surrounding tags, be it a div, a section, a span, a article or else. I need a simple trick to makeup those repeating blocks with a unique id. Anybody?
4. The template class must be extended with vars that are objects. One concept is to declare template-autotags, similar with current auto tags, but scoped within the template. Say '{[object:method parameter]}’ or '{{var}.method: parameter}' where object/var is set to a life object in stead of a replacement text. I don’t know if such mechanism would destroy cache-ability. But maybe someone has already experimented with autotags in templates. Help is appreciated.

I’ve finished a wiki page on Wireframes and GlPage. Started to define the wiki page GlTheme that should explain how a theme will be built. I intend to design a quite different directory structure to hold theme files, besides I’ll document the API. Please object if this is felt as a mistake.

Cheers,
Wim


On 23 Sep 2014, at 02:46, Tom <websitemaster at cogeco.net> wrote:

> If it meets with approval of the community and yourself I assume the 4th
> step would be to integrate the class into Geeklog and start the work of
> converting Geeklog and the other core plugins. A basic theme would need to
> be developed (or continued from the demo) to test our work.
> 
> BTW Hope you had a good vacation.
> 
> Tom
> 
> 
> -----Original Message-----
> From: geeklog-devel [mailto:geeklog-devel-bounces at lists.geeklog.net] On
> Behalf Of Wim Niemans
> Sent: September-13-14 7:10 PM
> To: Geeklog Development
> Subject: Re: [geeklog-devel] Geeklog 2.2.0 - What do we want?
> 
> 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
>> 
> 
> _______________________________________________
> 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
> https://pairlist8.pair.net/mailman/listinfo/geeklog-devel
>

More information about the geeklog-devel mailing list