[2.0] Smartifying the backend

Mark threads with "[2.0]" for discussions about features in the longer-term future, "[1.6]" is for short-term. This is not the place for general discussions or plugin or template requests. Only features that are approved to happen by the core team should be listed here for better structuring.
User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: [2.0] Smartifying the backend

Post by Timbalu » Tue Mar 06, 2012 1:59 pm

garvinhicking wrote:I don't see how this can be done, if the required code is outsourced to a smarty template? Then we would have duplicate code for the installer, once as a template and once within the PHP code. If this would happen, better put the whole installer routine ONLY in PHP, instead of duplicating it in Smarty...
I don't see this for now... Which required code is (getting) outsourced? Why should we move a try (smarty) catch (exception) react (throw nicely) code part to a tpl file? I need to test scenarious like this first to fully understand your concerns, I assume. :)
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
yellowled
Regular
Posts: 7090
Joined: Fri Jan 13, 2006 12:46 pm
Location: Eutin, Germany
Contact:

Re: [2.0] Smartifying the backend

Post by yellowled » Tue Mar 06, 2012 2:55 pm

garvinhicking wrote:We need to think about that the admin TPL needs to have a structure that at least allows bulletproof to still work properly; so changing things like that, you must think of the backleash on other templates that should still be supported.
How about keeping HTML4/XHTML templates for both backend and frontend as a fallback for legacy templates? The only thing (that I can think of) that we would need to make this work would be some kind of "switch" to determine whether a blog runs an XHTML or HTML5 frontend template. If the frontend is HTML5, use default-html5 as the frontend fallback (which would include a admin template in HTML5 as well), if the frontend still runs an old XHTML template, use default (an it's included admin template) as the frontend fallback. The only downside (as far as I can see) is we would have to ship both default and default-html5 (including their respective backend themes).
garvinhicking wrote:I think we can only change this, if we change all internal and spartacus themes to be able to deal with that.

Just saving code (and we are talking of maybe a kb!) ist IMHO not important enough to actually BREAK things, i.e. influence productivity.
Saving code, even if it is only a few KB (which is true), gives us better accessibility and performance in the backend, thus improving usability. If that means we (meaning: I) have to edit every fucking template from the stone age, so be it.

YL
amazon Wishlist - Serendipity-Podcast (German only, sorry)

User avatar
onli
Regular
Posts: 2280
Joined: Tue Sep 09, 2008 10:04 pm
Contact:

Re: [2.0] Smartifying the backend

Post by onli » Tue Mar 06, 2012 6:00 pm

Saving code, even if it is only a few KB (which is true), gives us better accessibility and performance in the backend, thus improving usability. If that means we (meaning: I) have to edit every fucking template from the stone age, so be it.
Is that still about exchanging classnames? If that follows a pattern, i could write a skript which changes the old templates accordingly.

User avatar
yellowled
Regular
Posts: 7090
Joined: Fri Jan 13, 2006 12:46 pm
Location: Eutin, Germany
Contact:

Re: [2.0] Smartifying the backend

Post by yellowled » Tue Mar 06, 2012 7:08 pm

onli wrote:
Saving code, even if it is only a few KB (which is true), gives us better accessibility and performance in the backend, thus improving usability. If that means we (meaning: I) have to edit every fucking template from the stone age, so be it.
Is that still about exchanging classnames? If that follows a pattern, i could write a skript which changes the old templates accordingly.
I don't think it's worth writing a script for something which can be done in a matter of minutes with a good text editor. :)

YL
amazon Wishlist - Serendipity-Podcast (German only, sorry)

User avatar
yellowled
Regular
Posts: 7090
Joined: Fri Jan 13, 2006 12:46 pm
Location: Eutin, Germany
Contact:

Re: [2.0] Smartifying the backend

Post by yellowled » Tue Mar 06, 2012 7:09 pm

yellowled wrote:How about keeping HTML4/XHTML templates for both backend and frontend as a fallback for legacy templates? The only thing (that I can think of) that we would need to make this work would be some kind of "switch" to determine whether a blog runs an XHTML or HTML5 frontend template.
Just to clear this up: By this, I mean something like engine templates for admin themes. That should be an equally good solution like it already is in the frontend, right?

YL
amazon Wishlist - Serendipity-Podcast (German only, sorry)

User avatar
garvinhicking
Core Developer
Posts: 30020
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany
Contact:

Re: [2.0] Smartifying the backend

Post by garvinhicking » Tue Mar 06, 2012 10:07 pm

Hi!
Timbalu wrote:
garvinhicking wrote:I don't see how this can be done, if the required code is outsourced to a smarty template? Then we would have duplicate code for the installer, once as a template and once within the PHP code. If this would happen, better put the whole installer routine ONLY in PHP, instead of duplicating it in Smarty...
I don't see this for now... Which required code is (getting) outsourced? Why should we move a try (smarty) catch (exception) react (throw nicely) code part to a tpl file? I need to test scenarious like this first to fully understand your concerns, I assume. :)
If react(throw nicely) has the completely well-looking HTML/CSS output and not just a dumb plaintext error, this would work. But then we'd have a lot of redundant HTML/CSS inside the react statement; which should not be in smarty in first place.

I really don't like using the "surrounding" smarty setup on first installation, this is VERY likely to fail very ungracefully.

Regards,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/

User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: [2.0] Smartifying the backend

Post by Timbalu » Wed Mar 07, 2012 10:46 am

garvinhicking wrote:If react(throw nicely) has the completely well-looking HTML/CSS output and not just a dumb plaintext error, this would work. But then we'd have a lot of redundant HTML/CSS inside the react statement; which should not be in smarty in first place.
OK, I'll check this as soon YL is near to ready.
garvinhicking wrote:I really don't like using the "surrounding" smarty setup on first installation, this is VERY likely to fail very ungracefully.
If so, converting installer.inc.tpl back to use PHP only as template engine, will be easy enough to do then I expect. :)
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
yellowled
Regular
Posts: 7090
Joined: Fri Jan 13, 2006 12:46 pm
Location: Eutin, Germany
Contact:

Re: [2.0] Smartifying the backend

Post by yellowled » Wed Mar 07, 2012 10:08 pm

I just noticed that neither the personal settings nor the general configuration are smartified. Both of them should be – generally, everything in the backend which contains form elements has room for improvement. A lot.

Any chance to get these smartyfied as well?

EDIT: Another point where I stumble: plugins.inc.tpl does not give me a reference to the JS for the drag'n'drop here which means all my editing to plugins.inc.tpl is kind of pointless. It's still a good idea to rewrite the underlying markup, but of course, the markup generated by the JS should be adapted to be well-formed as well.

YL
amazon Wishlist - Serendipity-Podcast (German only, sorry)

User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: [2.0] Smartifying the backend

Post by Timbalu » Thu Mar 08, 2012 10:15 am

For both its one of these functions in here
http://board.s9y.org/viewtopic.php?f=15 ... #p10429604
in this case serendipity_printConfigTemplate() taking them both.
We were not sure about hacking these functions as well, as they may be needed elsewhere...

Do you mean the $eyecandy script?

Edit:
I have send you a convert file
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
onli
Regular
Posts: 2280
Joined: Tue Sep 09, 2008 10:04 pm
Contact:

Re: [2.0] Smartifying the backend

Post by onli » Fri Mar 09, 2012 1:04 pm

Did Ian just smartify both functions?

User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: [2.0] Smartifying the backend

Post by Timbalu » Fri Mar 09, 2012 1:10 pm

No. I wasn't sure about pushing yet.
I'll send you the file, with all changes by now (serendipity_printConfigTemplate() and serendipity_printConfigJS()).
We still have to find out how to handle new/old backend needs delivered by these functions.
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
onli
Regular
Posts: 2280
Joined: Tue Sep 09, 2008 10:04 pm
Contact:

Re: [2.0] Smartifying the backend

Post by onli » Fri Mar 09, 2012 1:14 pm

Well, in theory and before i saw them: We just smartify them. In a first step, that won't change anything, as they still emit the same html-code. Than YL changes the Smarty-code and we have new forms.
They are used in different places, true, but always for the same purpose, and it aren't that many places anyway.

User avatar
onli
Regular
Posts: 2280
Joined: Tue Sep 09, 2008 10:04 pm
Contact:

Re: [2.0] Smartifying the backend

Post by onli » Fri Mar 09, 2012 4:17 pm

Garvin, we have an issue here.

The installer uses functions which are used elsewhere, serendipity_printConfigTemplate and in there serendipity_guessInput. Smartifying these functions would be great and - i think - necessary, because html5 improves forms a lot. YL, do you agree with that, is it necessary for your work?

But your concern regarding the installer is totally warrented. It can't be that the installer simply fails to emit proper html because smarty can't be initialized.
Smarty really depends only on templates_c/ being writeable, right? We have that check anyway on the first page. Wouldn't it be an agreeable solution to hardcode that very first page? Basically copying or integrating the existing functions. Afterwards, smarty should work, and even the installer could use the tpl-approach.

User avatar
garvinhicking
Core Developer
Posts: 30020
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany
Contact:

Re: [2.0] Smartifying the backend

Post by garvinhicking » Sat Mar 10, 2012 11:25 pm

Hi!

How about, for that function, not use smarty .tpl file but simple included php file that use the same parameters?

Another way that I thought about; is there any way to make Smarty3 work without having writable templates_c? Then this would erradicate the most common problem with Smarty...

If that is so, we could add an "!is_writable" check to serendipity_smarty_init, and use smarty in an evinronment that compiles the .tpl.php everytime without storing it...?

Regards,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/

User avatar
onli
Regular
Posts: 2280
Joined: Tue Sep 09, 2008 10:04 pm
Contact:

Re: [2.0] Smartifying the backend

Post by onli » Sun Mar 11, 2012 4:43 pm

garvinhicking wrote:How about, for that function, not use smarty .tpl file but simple included php file that use the same parameters?
Like a raw php-template?
garvinhicking wrote:Another way that I thought about; is there any way to make Smarty3 work without having writable templates_c? Then this would erradicate the most common problem with Smarty...
As far as I read, smarty needs such a folder. But one can set any folder, it doesn't have to be templates_c/ (and according to the docs, /templates_c/ like we use it - under the webserver-root - is a bad idea). Shouldn't it always be possible to create a temp-directory? We could use that.

Locked