Re: [binarycloud-dev] binarycloud vs. other web app frameworks

[Alex B. <en...@tu...>]

> i've been following the mailinglist threads for a few months now, and i
> must say it has gone up exponentially :) there's quite some action
> on the road ahead, with the rc2 api taking form... hopefully the code
> will start coming soon...
> 
> in the meantime, i was wondering how you guys would compare binarycloud
> to other webapp frameworks such as horde, zope; cms systems a la
> phpgroupware and groupit or even weblogs like phpnuke...

zope: mature
used an annoying custom markup language (DTML I think it's called)
uses its own database engine (?)
it's OS, but if just feels proprietary.

horde:
I was not aware that a 'framework' existed, it does. but is seems empty?
so, no idea.

cms:
binarycloud is not a cms. we are actually going to publish an extremely
groovy xml-based cms for binarycloud in the future, but the system itself is
not a cms.

re: phpgroupware, I offered to share components with them, but I looked at
the apps and they were full of echos for html, which is never a good sign :)
no production experience with this. seems 'flat' i.e. a phplib competitor
with a bit of structure added. overly oriented toward 'their' apps.

phpnuke:
headless monster. it grows really quickly, and some of the tools are useful,
but it isn't really for "deep" application development. sort of like phplib
if they had made it into a big collection of apps instead of just publishing
the core libs.

I should mention another tool, which though it is not mature, but has a
couple good ideas: SiteManager. hyper-OO, they abstract html which I
dislike, but they package modules nicely. XML Configuration too.

but we do all that in r2 :)

uh, so if I can huff-and-puff for a moment, I really haven't seen anyone
even trying something as deep as r2 with php. that wasn't really true of r1,
i.e. it had tools that existed elsewhere in different code - but r2 is
entirely unique.

the concepts and the code that will come out for this release will allow you
to speed the development of your projects by a factor of 5.

> i will start coding a web community site soon (for a youth movement),
> with a lot of dynamic content such as photographs, bio's, shortstories,
> communication between members..

cool.

> another thing i will want to do is delegate the content, so i will need
> some sort of cms system behind it, atleast for some area's of the site,
> depending on the member and her/his role in the movement.

Once we get a functioning r2 install, we're going to start in on a cms
immediately, would you like to participate in its development?

It will have a number of groovy features:
    -document version tracking
    -multi-language versions of the same document
    -an inline rich (read visual html) editor which works with IE5.5+
    -everything will be xslt
    -we might get around to building a caching module for ripping documents
...this would probably be generalized, though - so you can flag a page as
"cached" in the page def xml, and the system will automatically create a
repository for cached markup and check that first.

I think pear has a caching class, so we might just be able to plug it in!

> i think binarycloud (especially r2) looks very promising indeed, but
> don't you think the modules all by hand using the bc framework (or horde
> for that matter) will take alot more time and effort than starting out
> from a readymade cms system such as groupit?

This is a point, but what we're trying to do is actually much more
integrated with the system than "just a cms"

we're going to build a generalized entity editor, that will edit any defined
logical structure in the system.

around that, we're going to wrap an artificial hierarchy-creator/browser,
and we'll call the hierarchy browser plus the generalized entity editor "a
cms".

but the reality is that you'll just as easily be able to edit roles and
users are you are able to edit articles. this all comes from the idea of
entities, and the entitymanager.

I think the most appropriate way to "wrap" other projects is to convert them
to modules. The r2 module method spec is still a moving target, I just wrote
some code today that breaks the published docs. But with the first r2
init/core release, it will be final.

that means you can (fairly easily) wrap lightweight applications, as long as
they don't try to start a session.

however, part of the point of a system like r2 is to achieve complete
integration within the system - so all these other tools like entityManager,
rulemanager, eventmanager, etc won't be used by the code, and you won't gain
the advantages that come with that.

also, with the stuff we're doing, it will almost be easier to re-build a
simple app than to port it in. the new formbuilder will only spit xml out,
so we'll run that through a global xsl - that means you can write one xsl
for 90% of the forms on your site. one document.

for example, a forum:
    -define an entity: post
    -another: thread
    -another entity: forum

immediately, you can get a list of posts and a list of forums without
writing any more code. so far, you've spent 20 minutes writing 2 xml
documents. then you spend another ~30 minutes creating modules which call
the lister and form builder - which use global templates if you like, and
'bing' you have forums.

now, granted, you could spend a couple days doing that if you wanted
deluxe-o layouts, etc but overall the system will allow you to build
applications at ridiculous speed.

hope that clarifies a little for you :)

> [bash]:~$ man woman
> No manual entry for woman

but that would take away all the fun!


-alex

--
alex black, ceo
en...@tu...

the turing studio, inc.
http://www.turingstudio.com

vox+510.666.0074
fax+510.666.0093