Current status of facets branch

Ruby Apps Radiant CMS
1

Hey all,

After almost finishing my own extension of the page editing section
of radiant, I’ve just discovered the facets branch. Does anyone know
the current status and it it is likely to be merged with trunk any
time soon? I see Sean created it back in Feb and development sped
along until a few months ago.

I’ve got a small arsenal of extensions I need for my own purposes to
get my site off the ground that I’d love to share with the world, but
would prefer if they worked with the trunk version and not a branch
if only for the sake of trying to save myself headache in supporting
people.

Thanks,

Glenn

2

Glenn,

Facets is definitely “experimental”. From time to time since I created
it, people have asked when it will be merged back, but the only answer I
can give is “when it’s ready”. The branch was mostly a proof-of-concept
and is not ready for production. There are many things I’d like to
rewrite or rethink about it, and I’d like to expand its scope to include
the other interfaces as well. That’s a big task and it will take a
while to complete.

You are welcome to use it, but it will probably not stay in step with
trunk or the other branches until one of us has serious time to work on
it. That said, I’d gladly accept patches for it if you would like to
contribute.

Sean

3

-----Original Message-----
From: Sean C.
Sent: Monday, August 13, 2007 9:26 AM
Subject: Re: [Radiant] Current status of facets branch

Facets is definitely “experimental”.

I see there’s a “facets-lite” in the mental branch:

  • how stable is it?
  • could it be extended into the more complete facets system or would it
    have to be rewritten?
  • how far is the mental branch from merged into trunk?

Having this functionality, even a subset of the grander plan, would IMHO
do wonders for extension development. I’ve just set up one site using
Radiant and would like to use it more, but currently see the lack of
facets as a stumbling block.

If someone could give me a status update I could take a look at it?

Thanks.

Damien McKenna
Web D.
The LIMU Company

4

Damien,

I see there’s a “facets-lite” in the mental branch:

  • how stable is it?

It’s pretty stable, actually. That’s mostly because it’s trivial – you
can only add to the meta area and the area above the buttons. I don’t
see it persisting however, once we get more flexibility.

  • could it be extended into the more complete facets system or would it
    have to be rewritten?

There are a number of design flaws in facets that need to be alleviated,
and in my opinion, it might be easier to rewrite. ‘facets-lite’ was
just a nickname because I wanted to enable things like page_attachments
without the full-blown hyper-extensible model of facets.

  • how far is the mental branch from merged into trunk?

mental became 0.6.0, if you look at the changelogs.

Having this functionality, even a subset of the grander plan, would IMHO
do wonders for extension development. I’ve just set up one site using
Radiant and would like to use it more, but currently see the lack of
facets as a stumbling block.

What specific sections of the interface do you want to modify? Until I
get time to work on facets, the least we could do is put some more
flexibility in trunk if the request is reasonable, well thought out and
tested. Of course, you can always just copy the current UI and modify
it to fit your needs in an extension. If you have other extensions that
do the same, however, this could be sticky – see the recent discussions
about reorder/CopyMove.

As always, patches are welcome. Since it is open source, you are also
welcome to modify the codebase yourself.

Cheers,

Sean

5

Damien McKenna wrote:

So the facets-lite wasn’t for the pages view? I just found it by
searching trac for “facets”.

Facets-lite was only for the page editing interface, not the main
sitemap view.

What were the original goals of the project? How were you intending it
would work? What do you now want to change on it? If you could explain
this we might be able to help steer it in the right direction?

The original goals of the facets branch were to compartmentalize parts
of the page-editing interface so that they could be more easily and
unobtrusively modified. It operates on the principle that view
templates and partials define ‘regions’ that are filled with other
partials at render-time. You can define the contents of the regions via
the ‘admin’ object. The sample extension does a good job of showing how
to use the object.

There are some quirks to the interface, however, and I’m not sure it’s
in the right place of the API/application.

Right now I don’t have a clear answer on what I would want to change,
but my general feeling is that some things aren’t quite right. I’d have
to spend some time re-reading the code to see what needs fixing.

I was thinking a simply way to add an action column to the Pages list
would be an ample start to any grander plans, that would allow us to
start making extensions behave nicely.

This is one area in which facets needed to expand. It also needed to
cover the layout and snippets interfaces as well.

I’d like to be able to have the ReOrder and CopyMove extensions on the
same page, playing nicely. I can rework the extensions to suit, but
it’s tweaking the core I’m nervous about.

If you could document what you’d like Facets to do we could try to work
towards that goal?

Yes, but I prefer not creating more work for myself - when v0.6.5 or 0.7
rolls out with a replacement I’ll have wasted time getting.

Yes. As mentioned though if I’m going to help I’d like to at least be
working in the same direction as the main project, so my efforts don’t
go to waste.

Unfortunately, facets has become kind of the
cold-fusion-Perl-6-Duke-Nukem-Forever of the Radiant project. I agree
that the functionality is sorely needed; extensions that step on each
other are a real problem. Unless it becomes stable and mature, it won’t
be merged into any other branches or trunk before 0.6.5 or 0.7.

However, if you would like to contribute, I’d say first familiarize
yourself with the codebase and especially the tests. Then, checkout
facets and create a diff between it and trunk, then merge the changes
into your facets checkout. Once you have that, go after the most
accessible part of the code that you’d like to change. Write tests,
verify your changes. Submit a patch to the Trac. Since it’s an
experimental branch, if your patch looks good, I’ll be sure to accept
and apply it (once I find a minute… typing this email took a while
too!).

Sean

6

trivial – you can only add to the meta area and the area above
the buttons. I don’t see it persisting however, once we get more
flexibility.

(and later)

‘facets-lite’ was just a nickname because I wanted to enable things
like page_attachments without the full-blown hyper-extensible model
of facets.

So the facets-lite wasn’t for the pages view? I just found it by
searching trac for “facets”.

  • could it be extended into the more complete facets system
    or would it have to be rewritten?

There are a number of design flaws in facets that need to be
alleviated, and in my opinion, it might be easier to rewrite.

What were the original goals of the project? How were you intending it
would work? What do you now want to change on it? If you could explain
this we might be able to help steer it in the right direction?

I was thinking a simply way to add an action column to the Pages list
would be an ample start to any grander plans, that would allow us to
start making extensions behave nicely.

  • how far is the mental branch from merged into trunk?

mental became 0.6.0, if you look at the changelogs.

Mea culpa, I forgot that.

What specific sections of the interface do you want to modify?

I’d like to be able to have the ReOrder and CopyMove extensions on the
same page, playing nicely. I can rework the extensions to suit, but
it’s tweaking the core I’m nervous about.

Until I get time to work on facets, the least we could do is put
some more flexibility in trunk if the request is reasonable, well
thought out and tested.

If you could document what you’d like Facets to do we could try to work
towards that goal?

Of course, you can always just copy the current UI and modify it
to fit your needs in an extension.

Yes, but I prefer not creating more work for myself - when v0.6.5 or 0.7
rolls out with a replacement I’ll have wasted time getting.

If you have other extensions that do the same, however, this could
be sticky – see the recent discussions about reorder/CopyMove.

Exactly, I started that thread :slight_smile:

As always, patches are welcome. Since it is open source, you
are also welcome to modify the codebase yourself.

Yes. As mentioned though if I’m going to help I’d like to at least be
working in the same direction as the main project, so my efforts don’t
go to waste.

Damien

7

These things never come across well over email.

On Aug 19, 2007, at 8:52 PM, Jacob B. wrote:

My take is, the Core team isn’t ready to seriously review patches
and find a
solution. They’re procrastinating on the problem.

To say that the core team is procrastinating is a huge assumption on
your part. As far as I am aware, no one has stepped up to bankroll
the Core, so its more likely that they are busy with their personal
lives or even gainful employment.

Do you see what I’m getting at? No disrespect to the core team, I
think
they are doing a great job maintaining a solid stable product.

It is disingenuous to say that you think that they are doing a great
job after you accuse them of procrastination. You may have no
intention of being disrespectful, but it sure reads like it over email.

I just wanted to try to put out any fires before they get too big.
Email is not a good medium for nuance.

-Jim

8

Jacob B. wrote:

I too have tried to contribute to the expansion, improvement, and
re-integration of facets… twice now

Really? Did you announce your updates here on the mailing list? If we
miss something on trac, making a little noise about it here is helpful.

What ticket are we talking about?

–
John L.
http://wiseheartdesign.com

9

I too have tried to contribute to the expansion, improvement, and
re-integration of facets… twice now

My take is, the Core team isn’t ready to seriously review patches and
find a
solution. They’re procrastinating on the problem.

I think if I were to try a third time I would simply write a plugin that
duplicates all of the code of the current admin interface and then adds
the
needed ‘facets-like’ modularity. It’s really a hack and not the way it
should be done long term, but the power of Ruby makes it possible.

Once you write that ‘base-facets’ plugin and written a bunch of plugins
on
top of that… My theory is that you can more easily test the market for
your
facets-requiring plug-ins. If mainstream users of radiant can benefit
from
your admin-interface-changing plugin they are more likely to go through
the
effort of installing it and using it and giving honest useful feedback
if
they can simply install a set of extensions on their existing radiant
installation (as opposed to having to download an old branch)

THEN finally the core team will Know what they actually want the
‘facets-like’ functionality of the core radiant to be and properly
address
it.

Do you see what I’m getting at? No disrespect to the core team, I think
they are doing a great job maintaining a solid stable product. But if
you
want to experiment, build a plugin so everybody can install it onto
their
existing radiant. Once it’s really popular, then the core team will
accept
your patch to make it possible “The right way”.

And then I’ll be able to port my extensions… : )

10

So maybe “procrastinating” isn’t the best word

I first released this:
http://dev.eyebeam.org/projects/radiant-partatts/wiki

then this:
http://dev.radiantcms.org/radiant/ticket/508

There’s even this, demonstrating why I think we need facets-like
modularity:
http://demo.kupenda.org/ and http://demo.kupenda.org/admin/
(login: demo, password: radiant)

This is not a trivial problem. We’re talking about significant change
to
the inner workings of radiant to add a complete layer of view
abstraction.
This isn’t something that is going to be submitted as a single patch,
approved and just work.

We need to weight in on all the possibilities and explore the benefits
and
drawbacks to each. So that’s why I say, make some plugins.

11

my reason for needing modularity: Re-Introducing: Page Attributes, Templates, ContentFromTempl - Radiant CMS - Ruby-Forum

12

-----Original Message-----
From: Jacob B.
Sent: Monday, August 20, 2007 10:34 AM
Subject: Re: [Radiant] Current status of facets branch

This is not a trivial problem. We’re talking about significant
change to the inner workings of radiant to add a complete layer
of view abstraction.

You’ll have to pardon my naivity, but please help me understand why the
current system couldn’t be extended in two “simple” directions to allow
for what should cover most people’s needs:

  • Model to cover adding features to the list pages, i.e. the main Pages,
    Snippets and Layouts views, e.g. the existing ReOrder and CopyMove
    extensions.

  • Model to cover adding features to the editor pages, i.e. editing
    pages, snippets and layouts. Maybe let it select which internal
    function to allow the enhancement to show on.

Then in a subsequent itteration DRY it up.

IMHO (not having read the source code so I could be complete off-base)
this could be done over the course of three public beta releases:

  • 0.6.7-unstable gets the lists model,
  • 0.6.8-unstable gets the editor model,
  • 0.6.9-unstable gets some cleanup,
    and after further testing & fixing (and time for the extensions to be
    updated) it is launched as 0.7.0-stable.

Thoughts?

Damien McKenna
Web D.
The LIMU Company

13

Roger.

–
Travis B.
[email protected]

14

Hey guys,

Please excuse my naivety here, but what are the benefits to having
“facets-like modularity”?

Thanks,

–
Travis B.
[email protected]

15

  • Model to cover adding features to the list pages, i.e. the main Pages,
    Snippets and Layouts views, e.g. the existing ReOrder and CopyMove
    extensions.

  • Model to cover adding features to the editor pages, i.e. editing
    pages, snippets and layouts. Maybe let it select which internal
    function to allow the enhancement to show on.

This sounds good on a high level, but how do you go about actually
implementing it?
Is this a singleton model? one object covers the “page editing
interface”
and you manipulate that object to change that interface?
Or, can you instantiate new page editing interfaces

How does this “Model to cover adding features to the editor pages”
provide
hooks into extensions. If I were to create a “calendar” extension for
instance, I would want it to be page type. And when you select calendar
as
a page type I should see a different page editing interface. And when
you
click save, there needs to be certain callbacks to my extension. How
should
all of this work… it’s not clear.