I wasn't suggesting that the users should edit the xml files. Only
that the data should be saved as xml files. For easy sharing of
settings files. And if those files are kept in theme-name/settings it
would be simple enough to auto-add a dropdown for changing
settingsfile along with creating a new one and removing old. From what
I can think of this is a good solution and just because it’s not
following standard shouldn’t stop it.
One solution could be to just add an “export/import” settings as xml
button to the theme-admin interface. But the possibility to have
multiple configs is something I feel would be good.
On 20 Maj, 15:35, Arthus Erea <arthus.e...@gmail.com> wrote:
> XML is a "dangerous" format for users to play around with. We
> shouldn't expect end-users to be able to understand or modify XML.
>
> The current solution which I have developed is easy to use—users
> simply need to modify the theme within the admin interface.
>
> Theme authors can provide defaults within their theme.xml file. If
> they want a flexible system like you described, it would be easy
> enough to use "select" controls.
>
> Overall, I think the issue is about consistency. The rest of Habari
> uses FormUI, so theme config uses FormUI. The rest of Habari stores
> data in the DB, so we store data in the DB.
>
> On May 20, 2009, at 7:43 AM, eighty4 wrote:
>
>
>
>
>
> > Sorry if this have already been discussed, I don’t have the time to
> > read all posts. I don’t think the theme options should be stored in
> > db. It should instead be stored as an xml file. This would give ppl
> > two possibilities. Firstly users could exchange theme-files if someone
> > likes the colors, settings of a theme (s)he could easily get it from
> > the user that created the settings. Secondly the theme author could
> > include multiple setting files for a theme allowing the user to change
> > between them. This would require some kind of simple option to change
> > between settings files. (Shouldn’t be hard to just iterate a theme-
> > name/settings folder and add a dropdown for it.)
>
> > On 30 Apr, 03:52, Owen Winkler <epit...@gmail.com> wrote:
> >> Matthijs wrote:
>
> >>> Also, being able to use PHP in templates is a big plus for me. Say
> >>> you
> >>> want a special template in which you put a form for example, then
> >>> you
> >>> can just put any php logic needed inside that template
>
> >> Please allow me to correct one point:
>
> >> If you put PHP in a HiEngine theme, it will execute normally.
>
> >> If you were to change the theme you're using from RawPHPEngine to
> >> HiEngine and do nothing to your existing PHP, nothing different would
> >> happen -- your theme would look exactly the same.
>
> >> The HiEngine uses PHP stream classes to filter the template files
> >> before
> >> PHP includes them. It literally converts {hi:foo} into <?php echo
> >> $foo;
> >> ?> before PHP executes the template code. It leaves existing PHP
> >> code
> >> alone, and it is executed just like the code written by HiEngine.
> >> That's how it works. Implying that HiEngine somehow abstracts the
> >> PHP
> >> capabilities away from the themer is absolutely incorrect. They can
> >> easily be intermingled.
>
> >> Owen- Dölj citerad text -
>
> - Visa citerad text -
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to habari-dev@googlegroups.com
To unsubscribe from this group, send email to
habari-dev-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/habari-dev
-~----------~----~----~----~------~----~------~--~---
