01.13.06
Posted in FXweb CMS, development, open source, svn
at 12:57 am
Finally! Cca 2 months after first public announcement, sourceforge.net has opened beta testing of Subversion versioning system. And I’m proud to be among testers!
You can take a look at my repository – and check, if I’m not slacking ;) If it’s empty, it’s because they haven’t imported my svn dump yet, but that should be done within next day, I presume. Oh, the wind of freedom.
BTW, FXweb CMS will be released in nearest days. That is, within max. 4 days.
Tags: FXweb, open source, CMS, sf.net, svn, subversion
Permalink
12.21.05
Posted in FXweb CMS, open source, projects, webdev
at 12:06 am
I’m sure this question will pop up sooner or later from some of my friends or co-workers, so I’ll answer this way.
- Security: chance that someone will discover and report vulnerability raises with number of users. Open source = a lot of users.
- Developers: Anyone who modifies code has to release the changes – that means cost-free debugging and development. I know that this doesn’t mean that the project will just miraculously finish itself, but again – the more popular the project will be, the better chance of finding help.
- Bugs and ideas: Well, of course that only fraction of downloads will represent skilled developers willing to play with the code. But even regular users can help finding bugs and bringing new ideas, suggestions and comments to the project. Come to think about it, is there anything easier than complaining that something that you got for free, sucks? ;)
- Nothing lost: I don’t lose anything. Although it is technically and legally possible that someone will download, modify, install and do whatever he wants with FXweb and gets paid for it – but I really doubt that he will be in my vicinity and steal my clients somehow.
In other news, I’m learning JavaScript and will try to write some short tutorial soon and release FXweb CMS 0.0.2.
Tags: FXweb, open source, CMS, sf.net.
Permalink
11.23.05
Posted in FXweb CMS, projects
at 03:01 pm
I love using multidimensional arrays. It’s easy when you’re using PHP and have one mighty cool data type – mixed.
I’ve just finished tool for editing and reconstructing commands (objects) – that contain 3D array, which can contain another command object. Whew. I hope I’ll be able to release FXweb CMS 0.0.1 in nearest weeks.
Permalink
10.20.05
Posted in FXweb CMS, design, projects
at 05:09 pm
Oh my. I have to put it down, because I have total mess in my head. Plus I think that one is expert in given field when he can explain it to others.
So, the objective is to generate XML source from any given GPC data ($_GET, $_POST, $_COOKIE). I want to use templates, modules and elements for constructing the XML, site logic DB table for resolving GPC and some kind of ‘command’ object. So, what should do what?
Command object should be communication medium between anything and modules. It should contain array of commands that module (plug-in, see below) will understand.
Module (or plug-in, if you want) is… ehm… modular… module. It’s set of [un]installable files that provide coherent functionality – say, display a menu or site identity or whatever. This should be realised via elements – image, button, piece of text – piece of outputable data, as atomic as reasonable. Elements should be the only objects outputting XML, but I’m afraid it won’t be very practical.
And what are templates for? These are containers – set of sub-templates, module commands and maybe even elements (but I would advise against this behavior). This way, I can have some kind of default template – you know, the standard stuff – logo, menu, footer – and then just call module (or another template) that will provide main content.
OK, that was the easy part (or at least it may seem easy to come up with), the functional design. But I’m confused a bit about technical design. I know I could code something, but that’s just not enough. I don’t want to redesign my whole architecture and APIs later.
OK, let’s do simple and stupid functional decomposition:
- determine which main template we need
- call that template, all sub-templates, all modules (and elements, if any).
- and… that’s about it.
That sounded too simple (again). I didn’t even mentioned error checking, but that doesn’t matter now, I have a plan for that.
We need to have (sounds weird) defined default template. But how to determine if we need to use it, or some other?
At first, we’ll take a look into site logic DB table. If we found entry that matches our current GPC data, we’ll read command that’s there (or maybe cached file instead). That command will call everything needed – more modules or one complete template, or few templates and modules together – whatever.
When we don’t have anything in site logic, we could simply assume that user is manipulating GET data – and that would force us to put every single possible action into database. Or, modify code to check only part of GPC and generate rest (and I could think about this option). But it would be cooler if modules could recognise unallowed manipulation. So, we have to analyse that data.
How? That’s the question. $go ($_GET['go']) should tell us something about main content. $do should explain in one word what we’re gonna do. For example, $go = “shop” and $do = “top10″ should tell eShop module to output top10 products. If we’d need more data, they will have to be stored as serialised command object. Command object must have required attribute – name of the module/template/element we are calling. Now that explains a lot. But how will be processed? Will each module have to implement and interface to decompose message into tokens? Or will kernel include methods for translating the command? I don’t know yet. This is gonna be more complicated that I though it will be… but when it’s done, it will be well worth the time… I hope.
Permalink
10.15.05
Posted in FXweb CMS, PHP, design, projects, webdev
at 11:10 am
Ewww, awfully long title. But I don’t know how to express is by fewer words, so… on to the subject.
I’ve been coding new CMS in past few days, which won’t be released under any OSI-approved license, because it won’t be released at all. But I hope that the fragments of code and any gained skillz will make it to FXGAS, my open source project (which is codeless so far) someday.
My CMS can read static XML files and transform them via XSLT. Nothing special actually, that could be done in some 20 lines of code. Of course, that wouldn’t make it Content Management, nor System. It can analyse GPC data, look in the database and determine which XML to choose. This is all done by what I call ‘kernel’, or more specifically, class kernel. This is the only thing that’s instantiated by index.php and handles everything else. And, since I’ve used the name ‘kernel’, it should be able to load modules.
Now that was kinda problem. It wouldn’t be problem if I’d know what data modules need – but I don’t want to restrict them anyhow. I could have handled them all data, but that would unnecessarily increase memory usage. And nothing like calling public properties of instantiated kernel class didn’t work. Passing them by reference didn’t work either. Passing whole kernel by reference like $module->doStuff(&$this); didn’t work. And then…
I know I’m not very good at designing objects and stuff – I lack experience and time to read some of those nice books about design patterns. I didn’t want to use inheritance, because it just wasn’t suitable for my needs – PHP 5 doesn’t support multiple inheritance – and I don’t expect to have just one module. :)
So, when I finally realised that when I call preprocess modules with something like this:
// preprocess arrays stores names of pre-process module .php files
foreach ($this->
;preprocess
as $name) {
//strip .php from end and everything before last slash
$name = substr($name, strrpos($name, "/")+1
, -4
);
//run all modules from the list
$this->
;mod_pre
[] = new $name($this);
}
it gives the pre-process module just what I need – reference to the kernel! Awesome. No extra memory usage, no hassle with determining what data will module need. The only problem I see is that all properties had to be declared as public – and we ruin one of the cornerstones of OOP, encapsulation. But as long as we won’t let any rookie change important kernel properties we have no problem, I think.
So, now my baby CMS can call preprocess modules, which will replace in XSLT stylesheets with all transformations supplied by modules as well as in static XML content files with inclusion of all styles supplied by modules. Isn’t that great?
Permalink
