On Tue, Sep 30, 2008 at 5:13 AM, Arthus Erea <[EMAIL PROTECTED]> wrote:
> > On Sep 29, 2008, at 10:06 PM, Ali B. wrote: > > On Tue, Sep 30, 2008 at 4:53 AM, Arthus Erea <[EMAIL PROTECTED]>wrote: > >> >> Andrew and I talked about this on IRC and came to this suggestion: >> >> 1. Move admin and installer to /system/themes. >> 2. Rename admin to 'monolith' and installer to some code-name we >> decide upon. >> 3. Introduce a new <type> field into theme.xml, which accepts 3 values >> a. 'site' – used for public display; default >> b. 'installer' – used for the installer >> c. 'admin' – used for the admin >> 4. Create theme.xml for our themes and update accordingly. >> >> This serves a couple of useful aims: >> A) Ensures consistency of structure across /user and /system – all >> themes are in */themes > > > The suggestions are based on the assumption that the admin and the > installer are themes. Which, IMHO, is not correct. > The term 'themes' is given what controls the look and feel for the front > end. The admin and installer are sites, not themes. Thus, having system > front-end themes and the admin/installer sites in the same place would > result in an inconsistency, rather. This perspective also tells me that > having a "type" field in the xml would not make any sense either. > > > > I'm afraid you're incorrect there. They _are_ themes. > > They implement the theme system and use theme logic. Not to mention, they > really are themes in the technical sense. Themes are used to render > presentational logic–which both the admin and installer are. > Admin does not "implement" the theme system. The theme system is not just the Theme class. So no. For the technical proof, please look to line 67 of > http://trac.habariproject.org/habari/browser/trunk/htdocs/system/classes/adminhandler.php > . > > B) Allows for the ultimate plug-ability of alternative admin (or even >> installer!) themes. – eventually > > > On the top of my head, I can't see why you can't accomplish that --if that > that feature is implemented in core-- without moving these sites along. > > > I'm not sure how you would do that... presently the only ways are somewhat > hacky and rely upon plugins. > > By the way, what "sites" do you mean? We're not moving any sites.... > Admin and themes are. Or at least, this is how they're named. They have 2 different purpose, each is different from the front-end's. > > C) Potentially allows for the controlled activation of different admin >> themes – you could switch between different themes for the admin at >> will, just like for the public site. > > > Also can be implemented in core without moving the sites (see my previous > notes). > > Not only admin and installer are sites, but they are obviously 2 seperate, > different sites actually. And it makes perfect sense to me that they are > both in seperate folders, in /system. > > > Different sites? I'm not really sure where you get that... they're both > interfaces (along with the public front-end) to the same site. > > > > > -- > Ali B / dmondark > http://www.awhitebox.com > >> >> >> On Sep 29, 2008, at 9:38 PM, Andrew da Silva wrote: >> >> > >> > I was going to suggest not touching the user/ ... but then devs might >> > get confused? >> > >> > On Sep 29, 9:36 pm, Arthus Erea <[EMAIL PROTECTED]> wrote: >> >> I don't like the idea of reducing unnecessary complication, >> >> especially >> >> when it comes to the user themes directory. >> >> >> >> I don't know about you, but the URL 'user/themes/user/foo' seems ripe >> >> for confusion... >> >> >> >> My question is: why? What practical aim does this serve to users to >> >> justify this added confusion? >> >> >> >> What would be the problem with simply putting the admin and installer >> >> themes in system/themes/admin – I think we can safely assume nobody >> >> is >> >> going to name a theme "admin" – and if they do we should probably >> >> assume it is meant as a replacement for the admin interface. >> >> >> >> On Sep 29, 2008, at 9:25 PM, Andrew da Silva wrote: >> >> >> >> >> >> >> >> >> >> >> >>> Clutter in AdminHandler got me thinking... >> >> >> >>> Since admin and installer are themes, why are they still in >> >>> independent folders? >> >> >> >>> Sure, admin and installer in system/themes could be troublesome, but >> >>> would it? >> >>> We control what goes in system/themes... no risk of overwriting. >> >>> Only problem I can foresee is user/themes/admin and installer... >> >> >> >>> In the end, I think we should remove those two folders from >> >>> system, it >> >>> makes no sense anymore. >> >> >> >>> If installer is considered "administration" material, maybe we could >> >>> create... >> >> >> >>> system/themes/admin/installer >> >>> system/themes/admin/default >> >>> system/themes/user/k2 >> >>> system/themes/user/mzingi >> >>> system/themes/user/charcoal >> >> >> >>> And replicate in the user folder.. >> >> >> >>> user/themes/admin/... >> >>> user/themes/user/... >> >> >> >>> This way Habari would mainly be an API completely customizable >> >>> from A >> >>> to Z... >> > > >> >> >> >> > > > > > > > > -- Ali B / dmondark http://www.awhitebox.com --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/habari-dev -~----------~----~----~----~------~----~------~--~---
