By Date: <-- -->
By Thread: <-- -->

[XAR2] Proposal for directory layout reorganisation

linoj wrote:
> hi
> looks good so far :)
> 
cool

> Some initial questions
> 
> - are theme-specific module templates where I'd expect them?
> a modules/ subdir isnt shown in the examples, e.g.
> pathtoinstall/html/themes/mytheme/modules/abc/xyz.xt
Likely the module overrides will indeed stay the same, but see below 
on some notes on modules in general.
> 
> 
> - if i have site-specific php, where would that go? (eg like 
> xarpages/xarfuncapi, or other snippets)
  /path/to/instance/lib/ and below
> 
> 
> - where are properties kept?
>
see below

> 
> - I'm not sure what you mean by "somehow modules seem painful in this 
> layout, 'too big' comes to mind, 'too loose' too." ? i seems like you 
> have each module in its own subdirectory, right? not spread around
>
A module currently has its own 'ecosystem' and contains both php 
libraries (usuall below modname/xarclass or similar), API methods, 
images, templates etc. All in all a complex set of things, but nicely 
self contained, which is comfortable too.

The set on how to place all this stuff is now 'somewhat regulated' 
like the names of functions, api directories and template names. These 
'rules' are per module, there arent many rules to follow to make sure 
a module fits perfectly in the existing 'ecosystem' using its 
available resources to the fullest. Also, some of the rules are more 
to keep ourselves sane than a real reason from a technical point of 
view (not necessarily bad, but they may come across as ad-hoc 
sometimes) This is what 'too loose' referred to. If the rules were 
clearly extended from concepts started in core it would be easier to 
remember, to use and to embed. We are still (or I am at least) 
puzzling how to best do this, while keeping the good things we have in 
place too.

One level up, a module itself could be considered as part of the 
library of core, thus suggesting it would go beneath
   /path/to/install/lib  or
   /path/to/instance/lib

perhaps even further splitting it up and increase the 'granularity of 
reuse' (which is currently the module level)  Sometimes you want to 
reuse something from module X, but completely having module X makes no 
sense. At this point in time, there's no good way to do this. (but we 
want to have one) The 'too big' refers to this.

The above is the reason there are some details lacking from the 
document on module organisation The properties you mentioned for 
example are actually just derived php classes, so the likely place is
  /modules/modname/lib/ and below (i.e. treating them like any other 
php class in the lib(rary) for that module.

The same reasoning applies to module templates and their overrides. 
Many, many module templates are very similar to eachother. It strongly 
suggest making a more reusable concept (overview, modifyconfig, list 
view, consolidated data views) and do the overrides more based on the 
'type of screen' that is generated than the actual module template for 
such cases; not unlike what dynamic data does for its templates.

It's unlikely this can be applied fully. Any non-trivial module will 
add screens/functionality which are unique for that module and can not 
be classified according to some 'type' directly. As you notice, we're 
not completely there yet, specifying how that should work exactly. 
Forgetting (during design) how things currently work is the hardest 
part, as we're all so used to it.

> 
> - are we eliminating user api vs admin api?
> 
that is indeed the intent, while it is already possible to have 
xar<any>api at this time, we feel that the distinction is somewhat 
misleading and in some cases just causes duplication where, for 
example, a privilege based setup within one api would be more efficient.
How this will affect a website, which is typically 'lotsa anon, few 
authenticated' we have to figure out. One of the reasons to split 
things up was/is that the 'lotsa anon' parts should be as simple and 
speedy as possible, while the 'authenticated' parts may have a less 
optimized path through the code.


marcel
_______________________________________________
Xaraya_devel mailing list
Xaraya_devel (at) xaraya.com
http://xaraya.com/mailman/listinfo/xaraya_devel