Some MidCOM3 ideas
-
Henri Bergius
Some MidCOM3 ideas
Mon June 16 2008 15:49:21 UTCHi, all
We've been having some discussion about MidCOM3 UI lately. Next week
there will be a hack session about it so it would be a good time to
discuss them.
First of all, a major failing in MidCOM1&2 has been that not nearly
all features of the framework have been exposed via UI. Configuration
editing has always been a bit half-way, schema editing nonexistent,
and style editor got eaten by bitrot.
As we're starting from scratch with MidCOM3, I feel it important to
ensure the same doesn't happen here. We need simple but working UIs
that expose main MidCOM concepts to people also outside the "hard-core
Midgard hacker" audience. This means we need UIs for:
* Configuration (per-folder and per-site)
* Style editing (with knowledge of elements loaded in a view, and of
elements shipped with components)
* Route configuration (adding/modifying routes)
* Datamanager schema editing ("add field")
Only this way we can make MidCOM3 (and therefore Midgard2)
approachable to a wider group of web developers.
Similarly, we have to solve the problems that are in MidCOM deployment:
* Easy host setup (and reconfiguration to change hostnames, ports)
* Easy transfer and copy of styles, site structures and configs between hosts
For those ideas are welcome. I'm currently reading
http://reductivelabs.com/trac/puppet/wiki/PuppetIntroduction for
inspiration.
--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/
Skype: henribergius
Jabber: henri.bergius@gmail.com
Jaiku: http://bergie.jaiku.com/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: Some MidCOM3 ideas
Mon June 23 2008 12:47:34 UTCHi!
We have currently been using Midcom 2.8 for building a community site. The biggest challenge has really been the transferration and copying of styles and keeping them in sync between various dev-sites.
The important thing here is that when building site's layout there would be no need for asgard. You should be able to do all things (including ROOT) in commandline or with real editors without the needs of constant import & export like nowadays.
With Smarty it's possible and with TAL - templating I hope, it's possible to use completely separate place for templates that are stored normally in filesystem. Then you can access whatever templates you like directly from MidCOM and of course the very "ROOT" style can be defined in configuration. That would be really cool feature. That would also require us to define a "template-root" for MidCOM where it tries to look for additional templates.
Another thing that we should really consider is how do we preserve function names and API. That is very important with those calls that recur often in components. Wise decisions mean less search - replacing.
And from the performance point of view now it's also a very good time to think where to put some simple caching in order to prevent excessive database I/O. One of the greatest drawbacks with MidCOM 2.x is that when the server's load get higher the performance collapse just because excessive database punishment.
One thing that could enable us to minimize database I/O is Midgard additional database quering features. I think that "datagrid" [1] functionality and database table joins and grouping functions are something that could help us to think up new more efficient ways to do things.
[1] Piotras, Netblade and I had a chat about database "datagrid" at sweden. That could it is just an assoc array of data that can be joined and queries from multible tables.
-- Tero Heikkinen tero.heikkinen ( at ) rohea.com
-
-
Piotr Pokora
Re: [midgard-dev] Re: Some MidCOM3 ideas
Mon June 23 2008 16:59:03 UTCTero Heikkinen writes:
> Hi!
Hi!
> We have currently been using Midcom 2.8 for building a community site. The biggest challenge has really been the transferration and copying of styles and keeping them in sync between various dev-sites.
>
> The important thing here is that when building site's layout there would be no need for asgard. You should be able to do all things (including ROOT) in commandline or with real editors without the needs of constant import & export like nowadays.
Command line should be reserved for advanced users. Web interface for
newbies and those with basic knowledge.
> Another thing that we should really consider is how do we preserve function names and API. That is very important with those calls that recur often in components. Wise decisions mean less search - replacing.
What part of API?
> And from the performance point of view now it's also a very good time to think where to put some simple caching in order to prevent excessive database I/O. One of the greatest drawbacks with MidCOM 2.x is that when the server's load get higher the performance collapse just because excessive database punishment.
Once we have Style Engine abstraction in core I can add simple cache to
midgard-php.
>
> One thing that could enable us to minimize database I/O is Midgard additional database quering features. I think that "datagrid" [1] functionality and database table joins and grouping functions are something that could help us to think up new more efficient ways to do things.
>
> [1] Piotras, Netblade and I had a chat about database "datagrid" at sweden. That could it is just an assoc array of data that can be joined and queries from multible tables.
Yeah, though we need one basement functionality for QB, Collector and
DataGrid.
Classes and objects may be issue here, because we need to define the
scope of generated SQL.
Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] Re: Some MidCOM3 ideas
Tue June 24 2008 08:39:56 UTCHi,
We had a meeting about MidCOM 3 UI matters with Arttu yesterday, and
so I'm commenting based on the ideas presented there.
On Mon, Jun 23, 2008 at 7:59 PM, Piotr Pokora <piotrek.pokora@gmail.com> wrote:
>> The important thing here is that when building site's layout there would be no need for asgard. You should be able to do all things (including ROOT) in commandline or with real editors without the needs of constant import & export like nowadays.
> Command line should be reserved for advanced users. Web interface for
> newbies and those with basic knowledge.
For power users I would like to expose the structure of a site via
WebDAV. This means that MidCOM core should be able to intercept WebDAV
HTTP methods like PROPFIND and act accordingly to them. At first only
"core data" like pages, styles and snippets would be exposed, but as a
second part we could enable components to provide their own WebDAV
functionality to also make things like articles editable that way.
The way the MidCOM site structure would be shown via file manager
would be the following:
nemein.com (root page)
index.html (page content)
midgard_page.xml (full replicator XML, separate priv to see)
configuration.yml (parameter "midcom, configuration", separate priv to see)
news (page)
index.html (page content)
configuration.yml (parameter midcom, configuration)
important_press_release.html (article)
kuva.jpg (page attachment)
__style (host style)
news (style)
nnn-show-article (element)
__snippets (sitegroup config snippetdir)
net_nemein_news (snippetdir)
configuration.yml (snippet)
schemadb.yml (snippet)
This means that the page tree, configurations, style tree and
snippetdir tree would all be shown as a "filesystem hierarchy". A
developer could edit and create style elements using his favorite
editor, and copy-paste whole site setup between servers using native
file managers.
For power users the deployment of a prepared MidCOM site would thus be
quite simple: Install Midgard on target machine, use datagard to set
up an empty MidCOM host, open the new host as WebDAV mount, and just
drag-and-drop the site there.
But for end-users or first-time Midgard developers this all would of
course be too complex. Some UIs would be needed:
* Style editor
- Pretty much the existing style editor with some bug fixes and port
to MidCOM 3
* Config editor (YML tree)
- Check available keys from component defaults
- Special cases:
- Schemadb (select from existing, create new)
- Routes (always defined set of keys)
* Schema editor (YML tree, could be more wizard-like)
For these we made some UI sketches yesterday. Hopefully the picture
will illustrate our ideas:
http://www.nehmer.net/~bergie/midcom3-ui-sketches-20080623.jpg
> Piotras
/Bergie
--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/
Skype: henribergius
Jabber: henri.bergius@gmail.com
Jaiku: http://bergie.jaiku.com/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] Re: Some MidCOM3 ideas
Thu June 26 2008 06:12:29 UTCHi.
This webdav - idea seems to solve most of the power user's issues. Especially when editing things. What is the functionality of Asgard after this? Is it for the "First timers"?
Personally when I reflect this against the Bergie's git - idea I start to feel that there is quite good combination ahead. When you do things via webdav and edit site-wide settings of the midcom and components, I would prefer those changes are written to the filesystem. It helps developing and distributing things.
Of course a possibility to override stuff with database stored things is always a possible alternative.
But back to the issue at hand. As we have adopted MidCOM as a framework at our company the issue of the "hidden" features of the framework became very clean when we almost had implemented our own ui-message feedback before realizing that it has been built-in to the MidCOM. Thinking first how to reveal all services and features of the framework to the web-developer is important. This comes also to the documentation of things that comes in a way much more easier because there is an UI for the service somewhere that you can refer. Now it's quite challenging to tell people that read from the source to get an idea what the framework really offers.
- Tero
--
Tero Heikkinen
http://teroheikkinen.iki.fi
-
Re: [midgard-dev] Re: Some MidCOM3 ideas
Fri July 04 2008 13:03:21 UTCHenri Bergius schrieb:
> Hi,
>
> We had a meeting about MidCOM 3 UI matters with Arttu yesterday, and
> so I'm commenting based on the ideas presented there.
>
> On Mon, Jun 23, 2008 at 7:59 PM, Piotr Pokora <piotrek.pokora@gmail.com> wrote:
>>> The important thing here is that when building site's layout there would be no need for asgard. You should be able to do all things (including ROOT) in commandline or with real editors without the needs of constant import & export like nowadays.
>> Command line should be reserved for advanced users. Web interface for
>> newbies and those with basic knowledge.
>
> For power users I would like to expose the structure of a site via
> WebDAV. This means that MidCOM core should be able to intercept WebDAV
> HTTP methods like PROPFIND and act accordingly to them. At first only
> "core data" like pages, styles and snippets would be exposed, but as a
> second part we could enable components to provide their own WebDAV
> functionality to also make things like articles editable that way.
WebDAV would be really sweet but as someone who tried to work with the
pear webdav_server package (when hacking at midgard.webdav.styles) let
me warn you that it's pretty crappy: It flatly refuses to work in many
clients, in some (like KDE's kio slave) it randomly lost a few
characters at the end of the transmitted content, moving, renaming (and
deleting AFAIR) are not supported, so it might be hard to turn this into
a reliable admin interface. There seems to be some activity regardding
the HTTP_WebDAV_Server package, but the last release (in beta state) is
two years old. So who knows if it'll ever be released in a usable form.
>
>
> But for end-users or first-time Midgard developers this all would of
> course be too complex. Some UIs would be needed:
>
> * Style editor
> - Pretty much the existing style editor with some bug fixes and port
> to MidCOM 3
It would be nice if it could use some of the standard Asgard features
like Approval, Replication Information, RCs history, copy, move,
Codepress for syntax highlighting and so on. Admittedly I haven't really
worked with style editor yet, but I find the UI a bit confusing: Is
there any place where I can see the name of the style I'm currently
working on? Is there any way to see inheritance information?
F.x. If I have something like:
- Style 1
- Element 1
- Element 2
- Style 2
- Element 1 (overwritten)
Is there any place in style editor where it tells me that Style 2
inherits Element 2 from Style 1?
> * Config editor (YML tree)
> - Check available keys from component defaults
> - Special cases:
> - Schemadb (select from existing, create new)
> - Routes (always defined set of keys)
> * Schema editor (YML tree, could be more wizard-like)
User and group management could use some love, too. BTW: Is there some
way to implement su functionality in Midgard/MidCOM? I often have
support requests where people tell me that they can't see or do
something, and usually it's because of privileges. If I, as the admin
could say "change to userid x" and see the site with that user's
privileges, it would be way better than looking up his password in the
database, opening another browser and logging in with his account.
Bye,
Andreas
>
> For these we made some UI sketches yesterday. Hopefully the picture
> will illustrate our ideas:
>
> http://www.nehmer.net/~bergie/midcom3-ui-sketches-20080623.jpg
>
>> Piotras
>
> /Bergie
>
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] Re: Some MidCOM3 ideas
Tue July 15 2008 16:39:18 UTCMay I suggest you take a look at: http://www.ezcomponents.org/docs/tutorials/Webdav
I have no problems agreeing that Pears webdav component is a no go, having also tried using it.
While I like the idea of webdav, I am still wondering if not a lot of our content (styles, snippets and pages) is more filelike than db like and should reside on a filesystem rather than in a database. This would solve the problem another way.
A third way is finding a way to support JSR-170.
Regards, Tarjei
-
-
Re: [midgard-dev] Re: Some MidCOM3 ideas
Tue July 15 2008 17:18:21 UTCOn 15.7.2008, at 19.39, Tarjei Huse wrote:
> While I like the idea of webdav, I am still wondering if not a lot
> of our content (styles, snippets and pages) is more filelike than
> db like and should reside on a filesystem rather than in a
> database. This would solve the problem another way.
As a MVC framework point of view, especially performance in mind, I
also would prefer to see a possibility to make all configurations and
styles to reside in filesystem in order to minimize database
punishment. This should be designed in a way that PHP accelerators
can take a full leverage of it. With TAL that happens automatically.
For example substyles could reside in certain component's subfolders.
But naturally we need the possibility to store all configuration to
database. This enables us easily to use same installation on multiple
sites with multiple configurations. This should be done in a way that
again, minimizes database punishment,
Perhaps we should consider an approach where we first try to think
building good slim and modern MVC framework and think what features
are more CMS related. In theory when we move to the CMS building
process I would like to see it just as an "application" from the MVC
framework point of view. That way we do not pollute the midcom's core.
- Tero
--
Tero Heikkinen
http://teroheikkinen.iki.fi
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] Re: Some MidCOM3 ideas
Tue July 15 2008 21:07:04 UTCTero Heikkinen writes:
Hi!
>> While I like the idea of webdav, I am still wondering if not a lot of
>> our content (styles, snippets and pages) is more filelike than db like
>> and should reside on a filesystem rather than in a database. This
>> would solve the problem another way.
>
> As a MVC framework point of view, especially performance in mind, I also
> would prefer to see a possibility to make all configurations and styles
> to reside in filesystem in order to minimize database punishment. This
> should be designed in a way that PHP accelerators can take a full
> leverage of it. With TAL that happens automatically.
The most difficult part of midgard/midcom developing step was always the
need to read midcom's files, as it requires server's ssh access. I know
that web interface can easily encapsulate filesystem or database usage,
but with midgard's API the latter is provided out of the box.
As we do Midgard specific work we must have Midgard specific caching
built in midgard-php module.
This requires at least style engine and its contexts ( stacks, buffers )
clarification.
And going a bit further. If we have well defined style contexts API we
can easily adopt its usage for snippets, styles and pages. And then...
cache them. Files or database records.
Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] Re: Some MidCOM3 ideas
Fri July 25 2008 14:01:12 UTCHi,
On Tue, Jul 15, 2008 at 7:39 PM, Tarjei Huse <tarjei@nu.no> wrote:
> I have no problems agreeing that Pears webdav component is a no go, having also tried using it.
At the moment MidCOM3 WebDAV features use the PEAR library, but I'm
also following SabreDAV development to see if a more maintained and
modern PHP5 WebDAV library comes out of it:
http://code.google.com/p/sabredav/
> While I like the idea of webdav, I am still wondering if not a lot of our content (styles, snippets and pages) is more
> filelike than db like and should reside on a filesystem rather than in a database. This would solve the problem
> another way.
That is one option, but the problem is that much of styles and configs
are still connected to content structures that are in DB.
> A third way is finding a way to support JSR-170.
This would require reviving Midgard-Java, and AFAIK we have nobody to do it.
WebDAV at least is already done to some extent :-)
> Tarjei
/Bergie
--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/
Skype: henribergius
Jabber: henri.bergius@gmail.com
Jaiku: http://bergie.jaiku.com/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
