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

Wed Oct 1 20:56:59 EDT 2014

1. As far as I know no one is currently working on updating the themes
included with Geeklog to use the 'gl-' prefix. It has been a work in
progress. With the plans to redesign themes for Geeklog 3 is there any point
in continuing to develop these themes (beyond fixing bugs for Geeklog 2.x )?

2. I assume you are saying that the id's should be in template files only
and not generated by code? 

3. Creating a unique id is easy enough the trick is doing it in a logical
way that someone can figure out what the id is (for css or javascript
purposes). I guess we will need a naming convention for ids along with css
as well. In the page navigation example maybe we need to include a required
variable passed into the function that will add a suffex to the id. This way
whatever is creating the page navigation (like a plugin) can add in its own
suffix and thereby knows beforehand what it's possible ids are. Anyone else
have a better way?

4. If you have an autotag in a template and you have caching enabled then
the autotag output will be cached as well

>> I intend to design a quite different directory structure to hold theme
files, besides I'll document the API

Not surprised and I think it is needed

>> Please object if this is felt as a mistake.

No problem, and thanks for the work you have put in this so far. I will help
(and I am sure others) out when testing is needed and on other stuff when I
get a chance.

Tom

-----Original Message-----
From: geeklog-devel [mailto:geeklog-devel-bounces at lists.geeklog.net] On
Behalf Of Wim Niemans
Sent: September-30-14 6:53 PM
To: Geeklog Development
Subject: Re: [geeklog-devel] Geeklog 2.2.0 - What do we want?

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
> 

_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
https://pairlist8.pair.net/mailman/listinfo/geeklog-devel