You quoted the definition of the Templet. The Template stays as it is. Note the subtle difference in naming. A Templet is merely a technical solution that belongs to the functionality of the Template. As such a Templet could be used on its own and delivers parsed content.
Application is intended for all code that has the need to assemble some html widgets depending on all kind of variable circumstances, like we can find all over the place. Think of prepared sql-statements which technique is similar: a sql-statement with parameters ('??' and calls to replace them in order to avoid sql-injections.

Your proposal to have plugin-directories in the theme-directories is conform the current directories in the public_html. Looks good. Though is does not solve the slight problems that such a customised directory shows upon new releases of GeekLog: when the theme changes, I figure the customisations should change too. Another solution could be to have a non-selectable 'custom' theme that contains all the customisations either for a specific theme, either for all themes, either just for admin. I'm not sure, and consider this as a tough design problem.

Oops sorry about that remy.

How do you think backwards compatibility will work?

Geeklog and core plugins will be converted to the new page class (obviously) so do you think a plugin that supports Geeklog's 2.1.0 template system will work out by doing some sort of wrapper or will things be too different for it to succeed in all cases?

For this to work out we will need the major plugins to be compatible (the MUCH preferred way) or converted to the new class.

Plugins I am thinking of that are a must is

Forum Plugin
Downloads Plugin
Media Gallery
Captcha and reCaptcha

and I am sure there are others :-)

---

One of the Geeklog Core Developers.

Thinking of this some more we will also probably need 2 of the themes converted as well before the next release to use the glpage class. That would be:

Modern Curve
Denim

This is turning into a fairly big job...

---

One of the Geeklog Core Developers.

I think that glPage in first version will be 100% compatible. Use it or don't. That also means that the first version will be not so advanced. Just to have a taste and smell.

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. This module will only be sent in private on demand and not widely published.
Second will be the inventory of css-class names and adjust them with a standard rule (which is not yet available). When inventory is done I'll start a new thread on this topic.
Third is producing a demo site (and tar ball) with the most important functions (COM_ and ADMIN_) adjusted. Maybe some plugins are adjusted too, to show the difference in coding.
After that I don’t have more steps, or better, I don’t define the sequence of next steps. That’s up to the community.

I would like to add professional-css theme to the list.
I would suggest a rule on themes too:
-- a css-classs name is defined in templates (and referenced in css off course) and will not be added in php code; so there is always a one to one correspondence between css and templates
-- same for the naming of id's of the GL core
-- new releases always document the changes in class names and/or names for the id attribute, so theme developers know where to look

<p>It is rather hard to maintain more than one theme shipped with Geeklog core. How about choosing one from the existing themes, i.e., Modern Curve, Denim, Professional CSS, and Professional. Or I would rather see an entirely new theme based on <a href="http://getbootstrap.com/">Twitter Bootstrap</a> or <a href="http://getuikit.com/">UIkit</a>, which are quite popular and mobile-first.</p>

<p>As of glPage class, I suggest introducing the class in Geeklog-3.x, as there are already so many changes made in GL-2.x. I would very much like to see Geeklog refactored in an object-oriented way, but not in GL-2.x.</p>

---

-- mystral-kk, "Every cloud has a silver lining."

Makes sense. It is a pretty big change. This would allow us to release a version in the meantime (in the 2.x branch) with bug fixes and a few other smaller feature requests.



True.

I would still like to try and keep 2 themes with 2 distinct styles if possible. Not many people are making themes at the moment and it would give people who download Geeklog a few options. It also allows budding theme developers to see how different themes are put together and what is required to do it.

I don't know much about the different bootstraps but it would make sense to take advantage of one of them.

---

One of the Geeklog Core Developers.

<p>Remy has already created <a href="http://wiki.geeklog.net/index.php/Wireframes">new wireframes</a> in the Wiki and they are quite useful. It would not be so difficult to implement them based on Twitter Bootstrap (see <a href="http://getbootstrap.com/getting-started/#examples-framework">this page</a> or on UIkit (see <a href="http://getuikit.com/docs/grid.html">this page</a>. It would be foolish to reinvent the wheel by "rolling on your own."</p>

<p>Besides, as Remy said, it is important NOT to create HTML tags in COM_* functions. Some theme creators may use &lt;div&gt; tags to display a block, others may use &lt;article&gt; tags. However, the current CTL template class is rather helpless to take over what some COM_* functions do. So, I also suggest replacing the CTL template class with <a href="http://twig.sensiolabs.org/">Twig</a> (requires PHP-5.2.4+) or <a href="http://www.smarty.net/">Smarty</a> (requires PHP-5.x) in GL-3.x.</p>

---

-- mystral-kk, "Every cloud has a silver lining."

Twitter Bootstrap and UIkit are very usefull front-end framework.
concrete5 admin panel are based on Bootstrap already.
I hope strongly Geeklog admin panel based on font-end framework.
I added UIkit on http://www.geeklog.jp.

---

Geeklog Japan https://www.geeklog.jp

Have you been able to start coding yet remy?

---

One of the Geeklog Core Developers.

Inserted a pause of a few weeks.

Got the code ready and I am testing.

The code should be 100% backward compatible, so one could move to the new approach smoothly. In the same time this inhibits some advanced functionality, which is removed.
As far as feasible, some of them are using now old methods (COM_, _SCRIPTS, Template) and are limited. A example theme is abandoned since this would not be BC.
I am testing some familiar plugins and still fine tuning. Expect it end of november, including proper documentation.

Got the thing posted in downloads/hacks. Must wait for approval.

Version is 0.1.beta. Have fun !

Thanks Remy.

I will try it out this weekend!

---

One of the Geeklog Core Developers.

Okay I am getting the feel of how you have things setup.

For the test page you didn't include the resource files. Can you upload a new file with them?

---

One of the Geeklog Core Developers.

Posted glPage.0.2.beta. Waiting for approval.

These resource files are actual copies of your running install; well that was intended. I've added the copies of gl2.0 and a screenshot in examples.
Added fieldset tags to have a better understanding.

In the mean time I've developed a first app that is using bootstrap.css, jQuery and DB.

So far looking good Remy.

What's your next step?

---

One of the Geeklog Core Developers.

Next steps are written in ready.md in the download: a few modifications for better overview this year and extensions with several glCPO's next year.
I hope I get some feedback how people experience the usage.

In the mean time I've learned that using bootstrap 2 is bad for the current themes, since this version intervenes with a lot of tags and styles. Bootstrap 3 doesn't.
Same remarks on uikit and foundation, while the semantic-ui plays very nice.

Would appreciate remarks from dev's working with these frameworks.

Posted glPage.0.3.beta. Waiting for approval.

Finished the roadmap for 2014. Improved code for desk reading.

Added a example app, being form processing. This shows a simple form.
A second example is added, being the same form but now using a custom template.
The added examples are using bootstrap 3.

Next submission will be with a appropiate license, to be decided.
So, take it now since it is all yours to keep.

Working with this class, at least to me, is quite easy and frees technical tidbits from the design. I am using this class with bootstrap and wouldn't know when coding. It works very smooth with 2.1 and 2.0.

I see that the class is dowloaded some (65 times by now) and there was no feedback at all.
Which makes me wonder if the class is of use. Maybe one likes the code as an asset, maybe it doesn't work, maybe there is just satisfaction.

Meanwhile I am using the parent framework (boxary) for most work and it shows overall performance. So, I am reflecting on the issue 'should this class go ahead in GL'.
Please help me with arguments to use pro and con.

Hey Remy,

Bring this up in the developers mailing list. Dirk, Dengen and Mystral-kk (from Japan) are the other current developers of Geeklog.

I know I am extremely busy :-( at the moment... I am trying to find time for a Geeklog 2.1.1 release (and a few bug fixes along with the latest forum, ban and gus plugins) and I am having trouble. I know I will not have much time for anything new at the moment but I did like what I saw when I tested things back in 2014.

Maybe you need to create a branch in the repository and incorporate it (at least in part) right into Geeklog so everyone can review it and offer feedback.

We could also give you access directly to our Repository if everyone is okay with that.

It's easier to contact the developers through the mailing list than the forum.


Tom

---

One of the Geeklog Core Developers.