Install

[John Cox]

I got the install working up to the bootstrap. I forgot to ignore the
config file in svn, but I will fix that. Also if you get this error:

Server sent unexpected return value (502 Bad Gateway) in response to

Just try to recommit. I got it 4 or 5 times this morning, but it is a
bug with google code.

[John Cox]

On Jun 15, 8:15 am, John Cox <john.cox...@gmail.com> wrote:
> I got the install working up to the bootstrap.  I forgot to ignore the
> config file in svn, but I will fix that.  Also if you get this error:

It's working completely now. A couple of things that I am not sure of
though. I removed the javascript framework stuff since that's kinda
silly, but I might have broken the javascript tags. Also, the xaraya
classic theme only works right now with main module output, which is
to be expected. It just looks rough, but I planned on replacing that
anyway, due to the number of (again silly) includes to other
templates.

There is also one place in the install xaradmin file that has a giant
FIXME, as xarroles.php class wasn't being included from some point. I
added an include_once, but my guess is something else isn't working.

It's a little weird to see the xaraya core install down to 21
tables;) That said, I am thinking about removing the themes module
altogether, but still allowing the customer tags from the core. I
think we can set a theme name in a config var, and be done with it. I
think we can also still allow the overrides as well, without the
module. IE, if I throw a theme together, why should I have to install
it? Thoughts?

A couple of questions:

-> Any idea what the "tables" table does and where it comes from?

-> I missed pulling out the hooks table, I'll get that one. One more
thing about hooks. The reason I have pulled them out, I am assuming
that the applications are all self-aware. Since this is a development
system and not a user system, I don't see the need for them. Should
we discuss?

-> I see now the problem with the vars. Seems like a lot of
repetitive code, and overhead.

I am going to be working on basic themes next, and then I will get
into the profiler section. I also plan on seeing if my standalone ap
installs this week as well, so that should be a rather good test;)

Feel free to review what I have done, because it's been a long time
since I have looked at any of these core files.

[Jo]

On Jun 16, 5:42 am, John Cox <john.cox...@gmail.com> wrote:

> It's working completely now.  A couple of things that I am not sure of
> though.

I managed to install using the latest changes. It falls over at
completion during theme display with
Fatal error: Call to undefined function xarBlock_renderGroup()
I'll attend to it if you don't get to it first.

> There is also one place in the install xaradmin file that has a giant
> FIXME, as xarroles.php class wasn't being included from some point.  I
> added an include_once, but my guess is something else isn't working.

Ok, noted.

> That said, I am thinking about removing the themes module
> altogether, but still allowing the customer tags from the core.  I
> think we can set a theme name in a config var, and be done with it.

> think we can also still allow the overrides as well, without the
> module.  IE, if I throw a theme together, why should I have to install
> it?  Thoughts?

Agree. Apart from keeping a track of what is and isn't installed,
xaraya doesn't do anything with 'installed' themes in the UI so I
can't see why we need the extra overhead.

> A couple of questions:
>
> -> Any idea what the "tables" table does and where it comes from?

The tables table keeps track of all the table definitions - eg module
tables and fields (or is supposed to). This is done through the xar
tabledll core functions when installing/uninstalling modules. It is
also used specifically by some modules, eg dynamicdata for handling
table manipulations and so on.

> -> I missed pulling out the hooks table, I'll get that one.  One more
> thing about hooks.  The reason I have pulled them out, I am assuming
> that the applications are all self-aware.  Since this is a development
> system and not a user system, I don't see the need for them.  Should
> we discuss?

At this point, I can't see how they'd be used in a development system.
Unless the apis were of use somehow in an application?

> -> I see now the problem with the vars.  Seems like a lot of
> repetitive code, and overhead.

Yes definitely. These were amalgamated in xaraya 2x code to one module
var table (I probably would have renamed the table). There was also a
new 'itemtype' var with associated table also added in to fill a
perceived gap in what var types did exist. We don't have to go that
way but it's an example. We have quite a few different types now - do
we want to keep them all? System config vars, theme vars, module vars,
user vars - I'll start with removing theme var code given the apis are
going, and the code can definitely be consolidated/reduced. Any other
suggestions?

Question - xaraya 1x was still very much 'php4/php5' while xar2x had
converted to php5/classes and more OO approach throughout the
codebase. I had started moving my own 1x branch to php5/classes/OO in
some areas - do we want to do that?

I"ll continue on as per planned areas for working - variables, mail.

[John Cox]

Agree. Apart from keeping a track of what is and isn't installed,
xaraya doesn't do anything with 'installed' themes in the UI so I
can't see why we need the extra overhead.

I'll add that to my TODOs then.  I'll probably hit it after I start the profiler.

 

> A couple of questions:
>
> -> Any idea what the "tables" table does and where it comes from?

The tables table keeps track of all the table definitions - eg  module
tables and fields (or is supposed to). This is done through the xar
tabledll core functions when installing/uninstalling modules. It is
also used specifically by some modules, eg dynamicdata for handling
table manipulations and so on.

OK, there is no DD, is there any other value to it?

> -> I missed pulling out the hooks table, I'll get that one.  One more
> thing about hooks.  The reason I have pulled them out, I am assuming
> that the applications are all self-aware.  Since this is a development
> system and not a user system, I don't see the need for them.  Should
> we discuss?

At this point, I can't see how they'd be used in a development system.
Unless the apis were of use somehow in an application?

I don't see the need, as you should have direct access to everything when you are writing your application.  If we the thought is to leave them in, then it gets back to that harder development, methinks...

 

> -> I see now the problem with the vars.  Seems like a lot of
> repetitive code, and overhead.

Yes definitely. These were amalgamated in xaraya 2x code to one module
var table (I probably would have renamed the table). There was also a
new 'itemtype' var with associated table also added in to fill a
perceived gap in what var types did exist. We don't have to go that
way but it's an example. We have quite a few different types now - do
we want to keep them all? System config vars, theme vars, module vars,
user vars - I'll start with removing theme var code given the apis are
going, and the code can definitely be consolidated/reduced. Any other
suggestions?

I don't care about the table name.  vars is fine by me, or whatever you see fit.  I don't really see a need for the theme vars.  Module vars kinda make sense, but when I was writing my last application, I didn't use them once, and instead just dealt on the session level.  Session vars can be handled through html5, but there isn't a lot of support there yet, so they are needed.  config vars make sense.  

Just as long as there is a field for boolean / integer / string so we can set them in a foreach, I'm good.  We might want to scope them, but I'll leave that to you.

Question - xaraya 1x was still very much 'php4/php5' while xar2x had
converted to php5/classes and more OO approach throughout the
codebase.  I had started moving my own 1x branch to php5/classes/OO in
some areas  - do we want to do that?

Makes no difference to me to be honest.  OO is the way PHP is going, but if its going to take a long time to convert all the core, then it might not make sense yet.  Feel free to do the mail conversion in OO (although it's just a wrapper for the class anyway;), and let's see where that gets us:)

 

[John Cox]

On Tue, Jun 15, 2010 at 6:55 PM, John Cox <john.cox.ky@gmail.com> wrote:

Agree. Apart from keeping a track of what is and isn't installed,
xaraya doesn't do anything with 'installed' themes in the UI so I
can't see why we need the extra overhead.

I'll add that to my TODOs then.  I'll probably hit it after I start the profiler.

Actually, I started to look at this.  I've already moved the tables with no effect.  The only problem with removing the entire module is the CSS stuff.  I'm going to get it to install without moving the tags, and then fix it when I come back...