Serendipity Forums

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.

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

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.

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

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

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

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.

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

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

Did Ian just smartify both functions?

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.

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.

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.

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

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.