Kiss

[Auzzie]

I was just wondering why is there such a need to spread out the size of an empty extension? I understand that Aliro likes to separate Admin from User in regards to classes but is there really a need for 4 folders and several files in the root folder of it? For example the SEF file, couldn't a trigger be applied to the SEF class to allow any extensions that need to be called to have their SEF pulled from either a single XML file or maybe a database?
Just one of many examples that i could probably use for this question.

[counterpoint]

Interesting question

Some time fairly soon I'll probably rejig the precise structure a little more. But not before the latest Aliro code is packaged up as a release - to include the ability to parse PHP files to find where classes are located, thus removing the requirement to state in the XML what classes are included in a file.

But I wouldn't expect the number of folders to reduce as a result, although the number of files in the root of the structure might be smaller.

The first consideration is the intention to use some kind of MVC principle. On this account, it is assumed that there will be a set of "problem" classes that are used to model the entities that make sense for the particular application. That is the p-classes directory, although maybe it will change to problem-classes since not everyone finds the abbreviation to p-classes obvious.

Then there are controllers that receive control when a request is routed to the application, and invoke whatever actions are needed, using the problem classes to deal with the basic processing. That results in the introduction of directories c-classes and c-admin-classes, although again the names may get longer so as to make it completely obvious what they are for.

Finally, the controller will usually invoke a viewer, and so two more directories result, v-classes and v-admin-classes.

Of course, files do not have to be kept in separate directories at all, if the packaging is done correctly, Aliro will find classes anywhere, and you could move the files around to suit yourself, including the option of having no subdirectories at all. But I find it easier to develop applications if the code is spread across different directories according to its function. As you say, operations carried out from the administrator interface are entirely separate from those done from the general user interface. That increases the division into MVC classes from 3 to 5 (problem classes are common to both sides).

Three files can exist (they could go into another subdirectory if desired) for install, upgrade and uninstall - they are the code that will be run at the relevant time.

It might well be that sample.php and sample.admin.php are relics of older systems, since Aliro does not require any specific names for code, and can be controlled entirely by the class names given in the packaging XML. The code in those files could well go into the respective c-classes directories.

admin.newmenu.php is an oddball, and I'm not sure what would be the best location for it. It is a class that is invoked when a new menu entry is being built for the application, and allows total flexibility in the creation of possible menu options, under the control of the application.

index.html exists only to stop directory listings, although one might take the view that people should configure their hosting properly and not need lots of stray index.html files.

sample.class.php again harks back to earlier times, and should probably be abandoned in favour of putting the code into p-classes.

I'm very keen on standards, and sef_ext.php is as near a standard as one can find in the world of Mambo derived CMSs. The code in it implements the SEF Advance interface (where SEF Advance is unfortunately a commercial product, not open source). The code in it is loaded at run time by the Aliro SEF mechanism, and has the task of converting a query string relating to the application into a pseudo-directory string, and vice versa.

I haven't been able to see how your suggestion for use of XML or database would replace sef_ext.php - perhaps you could enlarge on that?

Obviously, if you only wanted an application that did next to nothing, all this would be overkill. However, I find that applications quickly become complex, and then, if I've started with a simpler structure, I wish that I had had a more substantial structure from the start. It is a lot of bother moving things around later on in development. I agree with KISS, but it is a matter of opinion what counts as simple! My feeling is that development is easier if each type of request is handled by a different controller (with the possibility of common methods in parent classes) and each display is handled by a different viewer. And then, I find it easier to have those classes in separate files, so that each one is a small and simple piece of code, which will not be loaded unless the appropriate kind of request is made.

Also, the generator assumes that it is a lot easier to delete unwanted files rather than to create new files from scratch!

Please note that a basic Aliro assumption is that all code for applications is contained within classes.

[wr1138]

"That is the p-classes directory, although maybe it will change to problem-classes since not everyone finds the abbreviation to p-classes obvious."

"That results in the introduction of directories c-classes and c-admin-classes, although again the names may get longer so as to make it completely obvious what they are for."

Allow me to strenuously agree with the principle of descriptive naming.
First thing I did after seeing those folder names was squint and furrow the ol brow.

"Finally, the controller will usually invoke a viewer, and so two more directories result, v-classes and v-admin-classes."

Do you mean to imply some semantic distinction between "View" (as in
model-view-controller) and "Viewer" (not precisely the view from mvc?).
Small thing maybe (small like the semantics of "extension" or "module"!),
but I just want to be certain I'm thinking what you're thinking.

"sample.class.php again harks back to earlier times, and should probably be abandoned in favour of putting the code into p-classes."

That too gets my vote!

"Obviously, if you only wanted an application that did next to nothing, all this would be overkill. However, I find that applications quickly become complex, and then, if I've started with a simpler structure, I wish that I had had a more substantial structure from the start. It is a lot of bother moving things around later on in development. "

Amen.

[counterpoint]

Yes, I'm sure you're right, I'll try to make the changes to the model soon. What seems obvious to the person who thought it up is often anything but obvious to others!

Oh, I get muddled about what term I really want to use in respect of the V of MVC! It seems wrong to call them views somehow, when we are talking of classes or the objects instantiated from them. Objects have behaviors and therefore seem more active, making the term "viewer" more appropriate. But "view" fits better with MVC and tradition.

You're also right about the structure. The problem here is that I've only gone a step at a time from the typical format of a Mambo application to something new. Maybe at some point it should have been completely rethought. Although I don't like rigid structures that where position actually has functional implications.

[wr1138]

Re: Packaging

Auto-discovering the classes is cool, but personally I wouldn't want to have to generate any of that xml by hand. I'd vote for anything that makes extension development as easy as possible, since so much depends upon a low-impedance contributor-experience.

Defining the parameters of input fields and controls seems like it could be easily automated. Parsing some html and extracting that info would be easy enough - how about using any wysiwig html editor to "wireframe" your forms and buttons, label it up there, parse that to generate the parameters part of the packaging xml...(?)

I guess the appropriate response is "sure, go ahead and build it".

[counterpoint]

I'm happy to agree on the principles

Parsing PHP turned out to be unexpectedly easy on account of the existence of a function to tokenize text. Unfortunately, I don't know of open source code that will parse HTML. If you were sure it really was XHTML it might be feasible to handle it with SimpleXML - but can one assume that developers have created 100% valid XHTML?

It might well be worth looking at making the code that generates the parameter HTML from information in the XML work kind of in reverse to provide a utility that would accept simple inputs to build a set of parameters. Or something like that!