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.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...
[2.0] Smartifying the backend
Re: [2.0] Smartifying the backend
Regards,
Ian
Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian
Ian
Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian
Re: [2.0] Smartifying the backend
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: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.
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.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.
YL
Re: [2.0] Smartifying the backend
Is that still about exchanging classnames? If that follows a pattern, i could write a skript which changes the old templates accordingly.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.
Re: [2.0] Smartifying the backend
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.onli wrote:Is that still about exchanging classnames? If that follows a pattern, i could write a skript which changes the old templates accordingly.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
Re: [2.0] Smartifying the backend
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?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.
YL
-
- Core Developer
- Posts: 30022
- Joined: Tue Sep 16, 2003 9:45 pm
- Location: Cologne, Germany
- Contact:
Re: [2.0] Smartifying the backend
Hi!
I really don't like using the "surrounding" smarty setup on first installation, this is VERY likely to fail very ungracefully.
Regards,
Garvin
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.Timbalu wrote: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.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 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/
# 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/
Re: [2.0] Smartifying the backend
OK, I'll check this as soon YL is near to ready.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.
If so, converting installer.inc.tpl back to use PHP only as template engine, will be easy enough to do then I expect.garvinhicking wrote:I really don't like using the "surrounding" smarty setup on first installation, this is VERY likely to fail very ungracefully.
Regards,
Ian
Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian
Ian
Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian
Re: [2.0] Smartifying the backend
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
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
Re: [2.0] Smartifying the backend
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
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
Ian
Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian
Re: [2.0] Smartifying the backend
Did Ian just smartify both functions?
Re: [2.0] Smartifying the backend
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.
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
Ian
Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian
Re: [2.0] Smartifying the backend
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.
They are used in different places, true, but always for the same purpose, and it aren't that many places anyway.
Re: [2.0] Smartifying the backend
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.
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.
-
- Core Developer
- Posts: 30022
- Joined: Tue Sep 16, 2003 9:45 pm
- Location: Cologne, Germany
- Contact:
Re: [2.0] Smartifying the backend
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
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/
# 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/
Re: [2.0] Smartifying the backend
Like a raw php-template?garvinhicking wrote:How about, for that function, not use smarty .tpl file but simple included php file that use the same parameters?
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.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...