Posted on: 08/31/14 09:53am
By: remy
Several functions are available to render a glPage that includes a proper header, footer and configured blocks. These are php functions and they return the html. Depending on the complexity of a plugin the programmer has to display the generated html in a proper sequence. Recently a summary function became available that can create the complete glPage in one go (createHtmlDocument). This php function also returns the generated html and the plugin is in charge for setting up its parameters in a php array.
Now, to make this more transparent and introduce a OO approach, a glPage class is proposed. Having such a class will influence the interfaces with the template class (caching), the blocks, themed headers, footers and so on. But the main difference is that the new glPage class will maintain the content that will be fitted in the final page in memory as opposed to returning on each call the resulting html. This means that plugins that adjust the generated html (in subtle ways after acquiring it thru the current php functions) would encounter problems in doing so. The procedure would be to adjust the html inside the glPage class what would require to extend the glPage class to a desired flavour.
So, instead of maintaing your php array for COM_createHtmlDocument, the gl way would be to hand over the content to the glPage class (and loose the visibility of the php array). And calling site header, siteFooter, startBlock, endBlock would be replaced by a single glPage access. The following is just a simplified example:
Text Formatted Code
Old method:
$display = startBlock() . $myContent . endBlock();
New method:
glPage->embedBlock($myContent);
glPage->render();
Please comment this first thought on glPage. If possible with real examples for the best and for the worse. Thanks.
Re: a new glPage class
Posted on: 08/31/14 11:37am
By: Laugh
I am glad to see a conversation started about the glPage class.
My first thoughts on this is that we have to make it backwards compatible with the current COM_createHtmlDocument functionality. This function and the related functions COM_startBlock, etc.. we can move to a depreciated library file that is loaded by lib-common. These functions can then become wrapper functions for using the new glPage class (where possible).
I do think though the functions COM_siteHeader and COM_siteFooter should be removed from Geeklog and not supported anymore.
How far do you want the glpage class to take control (in the first version of it and beyond). For example do you see it taking over direct access to the scripts class?
Expanding on your example above, how do you see this implemented with the glpage class?
Text Formatted Code
Old method:
$display = "";
$display .= "Generated Content Here"
$display .= COM_startBlock() . $blockContent . COM_endBlock();
$display .= COM_printPageNavigation($base_url, $curpage, $num_pages);
// Add JavaScript
$_SCRIPTS->setJavaScriptFile('javascript_foo', '/javascript/javascript_foo.js');
// Loads jQuery UI datepicker and timepicker-addon
$_SCRIPTS->setJavaScriptLibrary('jquery.ui.slider');
$link = COM_createLink('Link Text', $url);
$tooltip = COM_getTooltip($hoverover, $text, $link, $title);
$tooltip2 = COM_getTooltip($hoverover, $text, $link, $title);
$display .= "Generated Content Here with $link, $tooltip, $tooltip2";
$display = COM_createHTMLDocument($display, array('pagetitle' => 'Page Title'));
COM_output($display);
New method:
...
Re: a new glPage class
Posted on: 08/31/14 05:30pm
By: remy
Well, first is to realise that there is no glPage class yet. And second is to agree that a glPage class has some OO architecture and cannot break bc.
I think we must go ahead in this sequence. Starting with a proof of concept that bc is guaranteed is contra productive and will deliver just more overhead in the effort to create a proper class. This does not mean that a imaginary example cannot be produced.
Whatever glPage is needed, it has a close resemblance to the Template class because a page (in theory) is just a template. One may say that it has a layout, like left-center-right or similar, see
wireframes.
The class itself will have more methods, and it can be extended for specific content. As example, it will need (compared to the Template class) a method like addTvar or addTvalue in order to create a tVar that behaves like a array. As another example it is obvious that glPage will be extended with ajaxPage, mobilePage and so on. Also, a glBlock class might do the rendering of blocks.
My first intention is to get comments from the community on how they see the OO functionality that will obsolete some control that is available now, but can do a tremendous job for coding the main logic.
To reply to your quest for the example, here's a imaginary one:
Text Formatted Code
myPage = new glPage($title);
myPage->addResource('#1', '/javascript/javascript_foo.js');
myPage->addController('#2', 'jquery.ui.slider');
$myNavigation = myPage->addMethod(COM_printPageNavigation);
$myNavigation->render($base_url, $curpage, $num_pages);
$myToolTip1 = myPage->addMethod(COM_getTooltip);
$myToolTip2 = myPage->addMethod(COM_getTooltip);
$link = COM_createLink('Link Text', $url);
$myToolTip1->render($hoverover, $text, $link, $title);
$myToolTip2->render($hoverover, $text, $link, $title);
$myBlock = new glBlock($blockContent);
/* or myPage->setBlock('myblock', $blockContent); */
/* the page is constructed */
$reference = myPage->addContent("Generated Content Here");
$reference = myPage->addContent($myBlock);
$reference = myPage->addContent($myNavigation);
$reference = myPage->addContent("Generated Content Here with $link, {myToolTip1}, {myToolTip2}";
$display = myPage->render('Page Title'); /* the workhorse */
Please bear in mind that creating toolTips, navigation or pagination, lists etc. do not fit logically into a glPage class, except that they can be thought of as templates too. The example above demonstrates that one can create some snippets and stick them in the page. Even a page inside a page should be possible.
The $reference variable is not necessary and is contained in the code to show bc.
Than the first line might be new ajaxPage() or mobilePage() in order to render the wanted page as a response to a ajax call or create a responsive mobile page (with a different layout off course).
Re: a new glPage class
Posted on: 08/31/14 07:19pm
By: remy
Quote by: Laugh
How far do you want the glpage class to take control (in the first version of it and beyond). For example do you see it taking over direct access to the scripts class?
I see the scripts class as obsolete. The glPage class should replace that with a addResource method. The best solution is to contain such method in the template though, so you have all components in one place.
Re: a new glPage class
Posted on: 08/31/14 07:25pm
By: remy
Quote by: Laugh
Expanding on your example above, how do you see this implemented with the glpage class?
A minimal replacement would be available for the last two lines:
Text Formatted Code
glPage->addContent($display);
glPage->render('a title');
I do assume that the render method also outputs the page to a designated device or file (page, file, print, cli).
Re: a new glPage class
Posted on: 09/01/14 10:33am
By: Laugh
Please bear in mind that creating toolTips, navigation or pagination, lists etc. do not fit logically into a glPage class, except that they can be thought of as templates too.
Templates with logic (coding) behind it.... like a block. Should common Geeklog page objects still be stand along functions?
Re: a new glPage class
Posted on: 09/01/14 12:22pm
By: remy
Quote by: Laugh
Should common Geeklog page objects still be stand along functions?
I feel good with the response because this expression hits the essence and delivers a good name for the concept: (common) geekLog Page object. Thanks.
What happens all the time in the code is handing over small to big pieces of (html)text to distinguished functions, either core functions, either customised functions. The idea is that this text be better encapsulated in a object and handed over just the reference to the object. The object glPage will be just the beginning.
We can define object classes like glPage, glBlock, glSnippet, .... , which all are basically a Template object. 80% of COM_functions do create a template object and render the text before returning. By smart categorising these functions become the common geek log page object, and the named COM_function is just a stub to retrieve their respective encapsulated text. When glPage is a static class, it could operate as a factory for page objects. A named COM_function would then create a glSnippet object (which is a template), add it to the glPage object and render it to return the text. So far about bc.
The glPage class is responsible for constructing the resulting page and does so by collecting all common geeklog page objects in the proper sequence. This can be done using a template, as is currently done. This can be done by a pageLayout parameter with ID's.
To create COM_functions as objects (and be able to manipulate them in the named COM_function_stub), is very similar to this process.
What is needed is a very lightweight templet class for snippets like createLink, getTooltip, and such. Such a class would be capable to accept a string as template source, handle arrays and/or objects. Such a class would be recursive by nature.
An objection to this OO approach can be found in the complex code in some plugins to assemble a proper html tag, like other plugins struggle with assembling the correct SQL statement. The technique of working with so called SQL
prepared statements is similar to the snippet approach.
Another objection is the fact that you loose exact control over the generated html due to the encapsulation. My opinion is that this is overruled by page generating that fit distinguished frameworks like bootstrap, uikit, lemonade, etc. But first I would like to receive as extensive as possible comments on this discussion.
Re: a new glPage class
Posted on: 09/01/14 01:29pm
By: ::Ben
Nice idea this new class, but please keep a minimal compatibility with old plugins
As a plugin writer I need to be able to define the page tittle, display left/right/both blocks and content, add/load javascript or css. So, clear methods to do this will be a nice feature.
Can it be that this new class uses different layouts?
Text Formatted Code
myPage->setCSSFile('myplugin', '/myplugin/css/myplugin.css', false);
myPage->setJavaScriptLibrary('jquery');
myPage->setJavaScriptFile('myplugin', '/myplugin/js/monitor.js');
myPage->setJavaScript($js, true);
myPage->addContent($content);
$display_blocks = 1; // 0: none, 1: left, 2: right, 3:both
$layout = 'profesionnal';
myPage->render('Page Title', $display_blocks, $layout)
Ben
Re: a new glPage class
Posted on: 09/01/14 02:03pm
By: remy
Thanks Ben for your contribution.
Quote by: ::BenNice idea this new class, but please keep a minimal compatibility with old plugins
As a plugin writer I need to be able to define the page tittle, display left/right/both blocks and content, add/load javascript or css. So, clear methods to do this will be a nice feature.
The class will support full backward compatibility. Though I am not sure if mixing old style with new style is always a good idea. But lets see how this works out.
The class will contain clear methods to set (or configure) the desired layout. Writing this, it is obvious that it will support the (legacy) configuration options that are available.
Not yet resolved is how to handle themes and layout. GeekLog supports a lot of themes and generates several layouts. The (default) theme can be configured by the admin and the user. Than there are themes with a fixed or different layout, even responsive themes. There is a theme-switcher, even a language switcher. The intention is to introduce a layout switcher as well.
Would you share the opinion that maintaining the (dynamic) blocks layout (in reference to your code) is a requirement?
Than, the most important feature, the class would be used to embed a js framework and hopefully, would be able to switch the framework as well. But that is yet wishful thinking.
Text Formatted Code
myPage->setCSSFile('myplugin', '/myplugin/css/myplugin.css', false);
myPage->setJavaScriptLibrary('jquery');
myPage->setJavaScriptFile('myplugin', '/myplugin/js/monitor.js');
myPage->setJavaScript($js, true);
In my view stylesheets and javaScript are Resources of the page. The class will feature methods like addResource, addMeta, addLink in order to construct the head section. Other methods will handle the body element and the (not existing) trailer. Think of google analytics and html5.
Don't stop commenting now. Send in further requirements you have. It is appreciated.
Re: a new glPage class
Posted on: 09/01/14 08:55pm
By: Laugh
$display_blocks = 1; // 0: none, 1: left, 2: right, 3:both
$layout = 'profesionnal';
Hey Ben,
Why would you need to switch themes in code?
I was planning to switch over to a responsive theme at some point to make my site more user friendly. The problem I have is my site displays a large number of blocks which creates a real long page if you use a responsive theme (since the blocks, content, etc.. are all stacked on top of each other). One new feature I was thinking of for the next version of Geeklog was to define (user definable) certain modes based on screen size ... (need to research this more). I would then update the block editor and allow blocks to display only when one or more modes are detected. This way if my site is being displayed on a small screen it would automatically turn off non essential blocks and maybe enable ones that are more suited for a mobile screen.
I know this is not directly related to the glpage class discussion but I am just throwing the thought out their since we are talking about themes.
Re: a new glPage class
Posted on: 09/02/14 01:14pm
By: ::Ben
Why would you need to switch themes in code?
Displaying content in a complete different theme would be a nice feature. For exemole, if you display cooking infos or travel infos on the same site, it would be cool if you can display a custom header, footer, color and/or background. We could use a orange template, a blue template a red one... according to our contents.
Re: a new glPage class
Posted on: 09/02/14 05:59pm
By: Laugh
I had thought of something like that and combining it with topics. Depending on the topic a different theme would be displayed.
Re: a new glPage class
Posted on: 09/04/14 06:12am
By: remy
Interesting thoughts. Which are feasible already with current COM_createHtmlDocument(), as long as you set the theme in the beginning of the code; that is, before any template is processed. Not to say that the effect would be intentionally in the new glClass.
The real problem is, in my views, that the meaning of theme and layout is not clear. It can be something different for everybody. F.i. we talk of a theme but do mean the usage of template switching or we want a certain layout to be able to do theme switching; while the effects are realized by loading different templates.
If we can come up with a proper definition on what a theme is and what a layout is, than a clear API can be assembled. Since there are themes around that provoke a certain fixed layout, the task seems pretty urgent.
A theme is the look and feel of a geeklog website. Therefor it contains css, icons, a color-scheme, templates. It should never be case that the usage of a specific theme requires code changes. A theme is configurable (as is language too).
A layout is the frame in which the content is assembled and displayed. A layout can be designed using wireframes (what is a wireframe).[*1] It contains css, div-id's, javascript, templates. A layout is referenced in the code.
Now, when themes imply a specific layout, problems arise with layout switching because the css to glue components together appear in the theme files. In above defintion there is no place for this (we cannot 'name' the technique).
Also, when specific content needs a different look and feel (but with same layout), we incorrect name that as a different theme. In above definition this attitude could be correct, but clashes with configuration options. And in order to allow this in standard gl behaviour, we need a proper name for it (a subTheme or topicTheme, a motif, a resolution, a ...?)
Than, since gL2.0 a default theme is around. It contains valid css, icons, etc. to use when nothing is configured. There could be a default layout too, I guess. Which contains css, div-id's, etc. so themes (conform the above definition) should not have to bother about glue-ing components together in a custom way: they must refer to glStandard naming of the layout.
So the question is: what is exactly a theme, what might it do, and what is a layout, how should it be glued?
Additional we should properly name subThemes and alike. Do we still allow themes and layout to intermix?
Thoughts, comments, innovations?
Re: a new glPage class
Posted on: 09/04/14 07:22am
By: Laugh
I like your definition of Geeklog layout's and themes. It makes sense.
Using your definitions I do not see the need to switch layouts in code beyond what the current layout provides. Allowing this would increases the complexity too much for little benefit. The only time I would see the layout being changed is if the user picked a different one (if available) from the user preferences.
I can see developers wanting sub-themes or at least alternate templates depending on the topic they are in or some other variable. Sub themes should just contain any changed templates or images. If the template file is not there then the main theme template file is used. This will allow for easier updating of themes when a new version of Geeklog comes out. Most people who use Geeklog tend to use one of the main themes and just change a few files.
Sub-Themes may not be the best name though... It makes sense to call it this when the change happens based on a setting or code and while the main theme is still the "main theme". For someone who creates a sub-theme (as described above) by changing the header and a few other template or graphics to act as the main theme it may not.
When I had thought about the topic theme change idea I had thought of a few other ways around it. I could of used an “if” construct in the template file to do the changes I wanted or even added a variable like so just to change an image:
Text Formatted Code
<img scr="http://mysite.com/images/{current-topic}rest-of-image-name.gif">
I am just throwing that out as an example as there are ways around things.
The one thing we should try to do is make it easy for people to update their themes and try to balance the complexity, readability and usability of the layout and theme (from a creating point of view. easier said than done :-)
Re: a new glPage class
Posted on: 09/06/14 07:54pm
By: remy
Rethinking and evaluating the comments, I do suggest to use the naming of skin, layout and theme. I also introduce template and resource. Please read and comment:
A skin is a look and feel concept that can be applied to pages or their components. It contains a set of browser instructions. Therefor it bundles css, icons, a color-scheme. It should never be the case that the usage of a specific skin requires code changes other than invoking them.
A layout is the frame in which the content is assembled and displayed. A layout can be designed using wireframes (what is a wireframe). It contains css, div-id's, javascript and templates. A layout is referenced in the code.
A theme is the look and feel of a geeklog website, the sum of layouts and skins. It should never be the case that the usage of a specific theme requires code changes. A theme is configurable (as is language too).
A template is a general purpose macro text body that reflects the blueprint for a page or page component. Templates are used for layouts (and refererence by design the (wire)frames). And complex themes may embed their skins in them too. It consist of content (text) with replaceable parameters (variables), get parsed and may be recursive, either in itself, either by code.
A resource is anything that is needed to render a page in the local client (the browser). Resources of a page may vary depending on characteristics of the connection, on the (type of) browser and even on the device that runs the local browser: think of a page that is loaded by a browser script; since we think of pages as a central concept, the script that loads the page is a resource of the very page.
Current resources are limited to style sheets (css) and javascript (js). Resources can show mutual dependency; style sheets cascade and javascripts might depend on a library.
Geeklog, as a portal or CMS or blog or else, delivers in general a complete web page on a (http) request. This response consists of http-headers (amongst them cookies) and a html document. The structure of the html document is identified by a doctype as the first line. What follows is the document which is generally structured with a html-tag, head-node, title-tag and body-node. glPage and components governs only the body-node, but might access geekLog Core to construct the head-node and title-tag.
This body-node comes with a standard geekLog layout as default: header - body - footer.
While header and footer are represented in current themes as a template, body is not. This is considered as an error. There should be a body template that enables the theme to configure right-, center- and left-blocks. Being a geekLog standard too, the body-component of the body-node should have the default layout of left - center - right.
Note. Plugins often just manipulate a specific block, add a block to left or right, or construct a center. Numerous variations exist to build a menu, search box, login box, and differ only in the placement: be it in header, as a left-block or a custom-block in center.
While the contents of left and right is configurable, center is not. This is not seen as an error, though it is pretty difficult to insert a custom block on a certain relative position into left or right. It must also be clear that 'movable' blocks, f.i. login box and search box, are in need of a different rendering depending on the placement in f.i. left or header.
Note. Plugins (and staticpages) do have the requirement to optional suppress left and/or right and sometimes header and footer also. There is a Core setting that allows for that.
It is obvious that the user functions, which are delivered thru code, are in need for a flexible placement on the resulting page and must not be duplicated in themes, be it in code or in templates, what is the current praxis.
Example. A story might show a login box. The thinking behind this is that the site does not offer a login, unless the story is read first (a registration box would be a better example yet). However, having a few landing pages with a story that embeds a login, might enable you to track the starting-point of the user and act upon that.
To be continued.
Re: a new glPage class
Posted on: 09/07/14 08:27am
By: Laugh
I agree with your evaluation. The only thing I would change is the order listed:
Resource
Template
Skin
Layout
Theme
Re: a new glPage class
Posted on: 09/07/14 07:58pm
By: Laugh
So thinking about Themes a bit more.
I am assuming Skins would be tied directly to Layouts (ie you can't share a skin with another layout). A default skin will have to be defined then for that layout incase Geeklog or a plugin calls to use a skin that does not exist. I guess the same logic would apply then for layouts then... A theme would have a default layout (if there is more than one).
I am use to the current Geeklog theme structure and I have dabbled in Joomla a little bit. How do you see the file structure for a theme that has multiple layouts and skins?
With layouts how will Geeklog know which layout to use with the new page class?
Currently blocks are displayed based on 3 things.
1. Security the user has
2. What topic they are in (All, Homepage Only, Selected)
3. Left or Right Side
How do you see Geeklog Layouts handling this? With your wireframe wiki page it shows there can be more than just the left and right columns. I guess we would have to expand on #3... (and rename column to something else)
Re: a new glPage class
Posted on: 09/07/14 09:27pm
By: remy
Just a quick answer. It is very simple, and thought out-of-the-box. First a short intro.
Templates are used to tie a layout together, currently. One would expect the following template available (but it isn't yet):
Text Formatted Code
template index.thtml (or page.thtml):
{header}{body}{footer}
We'll find a header.thtml and a footer.thtml, but no body.thtml.
Text Formatted Code
candidate template body.thtml:
{left-blocks}{center-content}{right-blocks}
GeekLog Core assembles the blocks for left and right and the plugin creates the center-content. A template is used by glCore to avoid coding in php.
The concept is that one ties a template to a layout (by name) in stead of defining the layout inside the template, as shown above. The confusing part is that a layout is a structure of templates. My view is that glPage maintains a array with elements that identifies a layout and the php-code refers to these id's. Well, not exactly a array of id's but merely a tree of layout components. Valid id's would than be (long form): header, body, body:left, body:center, body:right, footer. The coder would assign a template to such id as opposed to creating a template and assigning the finished content to a variable in the main template.
Example: A plugin could create id's like header:search or body:left:search and assigns the search-box.thtml template to it.
To answer the questions:
A page consists of several boxes (rectangles). We might group them by function, topic, security or else. Important is the grouping by position on the screen (the layout).
Now, every box must be seen as a page too and glPage assembles all those 'pages' into a layout (a page too). A tree of pages is constructed in memory, and every page can have many child-pages and has exactly one parent-page.
A skin is a skin; a theme consists of one of more skins; the current skin is applied to the layout it is set for. In extremum 'header' could be orange skinned, 'body' blue and 'footer' light-green. Additionally the skin of 'body' could be customised too: 'left' could be pink, 'center' dark-red and 'right' mint. Skins cascade as css does.
A theme has a default layout which is identical to the geekLog default layout. Since a layout is a template, the theme might adjust the default templates (or not) for this layout.
GeekLog 'knows' about one layout: page: [header, body: [left, center, right], footer] which happens to be the concept of GeekLog. The new glPage class knows only one layout, and custom layouts can be attached to any component of the known layout, building it's own themed and skinned pages.
Maybe a theme would be able to configure the layouts to use.
For selective blocks there will be no changes. Though it would be wise to rethink that.
The file structure of a theme would be better change, since it is a extensive melting pot of all kind of ideas, some smart, some obsolete. I do think that the directory-name of a theme is of no interest to the plugin and must be magically discovered by glPage.
A bigger problem is that a lot of code generate html attributes scattered all over the place.
These should be in (theme) templates because that is the first principle.
Re: a new glPage class
Posted on: 09/10/14 08:55am
By: remy
There is a page now on the wiki
http://wiki.geeklog.net/index.php/GlPage[*2] .
I do realise that the audience to glPage is populated with besides php coders, also web designers. Descriptions and discussions are not special focussed on one of both skills. That might make the rumbling a bit vague.
While walking thru the theme directories it became very clear that templates are very, very customised to the current code. F.i. there are 4 list.thtml, even a specific directory for several formats and block-templates come in all kinds of flavours with an accompanying block-header and block-footer, while the only difference is the classname of the surrounding div-tag. Cleaning up will take a while, which is a understatement. This also looks like that the planned skinning feature would not work with such a massive amount of classnames.
But the most frightening experience is that in a lot of places javascript files are set to load, specifically jQuery components. Obviously it was very difficult to have jQuery smoothly implemented. Eliminating or bypassing that will take a separate configuration module, I guess.
For now, I do assume that a theme will have a configuration. Actually it has one (in functions.php), but most of the parameters are of no use with glPage. So this has to be redone and a skin will probably become a callable php-script, like skins/orange.php or skins/modals.php or skins/admin.php to suggest a few. Such script will have a php-function defined that accepts a layout parameter (which is a string or the object tbd).
The theme directory should contain a template for very layout used, with page.thtml as the root template. Optionally that is, because a layout might contain several layout-nodes. This means that a template-file-path must be scriptable like a template variable. To start with a first implementation of glPage, the default layout for GeekLog is set to 'header, body, footer' and the 'body' is default extended with the layout 'left, content, right'. Plugins will hook onto 'content', I guess. Second, a 'resources' directory should be present that contains all css and css-subdirs if necessary. Third, same for 'images' and 'javascript'. On the other occurrences I don't have a opinion yet. Proposals?
Re: a new glPage class
Posted on: 09/11/14 07:02am
By: Laugh
On the wiki glPage you define the template as:
A templet is the workhorse of the template. As opposed to a template that accepts a tRoot (template root directory) and loads the macro text from files, the templet accepts a inline parameter as macros text. Obviously templets process short macro's, also called snippets. A templet is not cache-able.
In the current system templates can be cached and some templates like those dealing with stories, topics, staticpages, etc. can be cached to include the (or part) of the content that is processed by Geeklog. This caching does result in some major time savings depending on what is included in the page.
I assume the javascript directory for the theme will include just the theme specific javascript files. Geeklog will still have it's own JavaScript directory for jquery, etc...
One thing I think can be improved on is plugin template customization. Currently most plugins rely on the user to update the templates in place. This makes multi theme websites difficult as well as plugin updates difficult (since the customizations get over written). One idea to fix this maybe is having a plugins directory in the theme directory. In here Admins can add directories for the plugins they want to customize and in those directories any templates that have been customized. The template class can then look into the "customized" directories first and then fallback to the original plugin template location if no customized template file(s) are found.
Re: a new glPage class
Posted on: 09/11/14 07:30am
By: remy
On the wiki glPage you define the template as:
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.
Re: a new glPage class
Posted on: 09/13/14 09:18am
By: Laugh
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 :-)
Re: a new glPage class
Posted on: 09/13/14 09:35am
By: Laugh
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...
Re: a new glPage class
Posted on: 09/13/14 07:34pm
By: remy
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
Re: a new glPage class
Posted on: 09/13/14 10:06pm
By: mystral-kk
Quote by: LaughThinking 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...
<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>
Re: a new glPage class
Posted on: 09/14/14 03:51pm
By: Laugh
As of glPage class, I suggest introducing the class in Geeklog-3.x
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.
It is rather hard to maintain more than one theme shipped with Geeklog core.
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.
Re: a new glPage class
Posted on: 09/15/14 06:58am
By: mystral-kk
<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 <div> tags to display a block, others may use <article> 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>
Re: a new glPage class
Posted on: 09/24/14 04:27am
By: ivy
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.
Re: a new glPage class
Posted on: 10/24/14 06:43am
By: Laugh
Have you been able to start coding yet remy?
Re: a new glPage class
Posted on: 11/04/14 12:57pm
By: remy
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.
Re: a new glPage class
Posted on: 11/27/14 11:09am
By: remy
Got the thing posted in downloads/hacks. Must wait for approval.
Version is 0.1.beta. Have fun !
Re: a new glPage class
Posted on: 11/27/14 04:26pm
By: Laugh
Thanks Remy.
I will try it out this weekend!
Re: a new glPage class
Posted on: 11/29/14 10:19am
By: Laugh
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?
Re: a new glPage class
Posted on: 11/29/14 11:38am
By: remy
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.
Re: a new glPage class
Posted on: 12/01/14 09:51pm
By: Laugh
So far looking good Remy.
What's your next step?
Re: a new glPage class
Posted on: 12/06/14 10:39am
By: remy
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.
Re: a new glPage class
Posted on: 01/01/15 08:27pm
By: remy
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.
Re: a new glPage class
Posted on: 06/11/15 08:56am
By: remy
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[*3] ) 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.
Re: a new glPage class
Posted on: 06/11/15 09:17am
By: Laugh
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