Thursday 24 February 2011 2:11:31 pm

Please, don't take this as a promise or anything, but as far as I'm concerned, your cry for help isn't ignored. Without digging into implementation details, the idea of making anything displayed with {attribute_view_gui} is very sexy. Really. We couldn't deliver as much as we wanted to regarding front-end editing for various reasons, but the topic is far from being abandoned.

I hope this makes you feel at least a tiny bit better (digital hug) ;-)

Bertrand Dunogier
eZ Systems Engineering, Lyon
http://twitter.com/bdunogier
http://gplus.to/BertrandDunogier

Thursday 24 February 2011 2:49:06 pm

Hello Eirik

Attribute level editing has surfaced quite a few times in the past. The content model implemented with eZ Publish makes it quite hard to achieve this (editing an attribute means editing the whole object).

See for example the discussion http://share.ez.no/forums/setup-design/is-it-possible-to-edit-only-1-attribute-of-a-contentobject a bit over 3 years ago

So its not new, but it requires some fundamental changes in the paradigms used by eZ Publish (which I proposed as part of Project V)

Paul

eZ Publish, eZ Find, Solr expert consulting and training
http://twitter.com/paulborgermans

Friday 25 February 2011 2:14:34 am

Hi all,

Re: inline attribute editing.

I've been working on extension to do this. It's kind of half-way through but I don't have the time to finish it at the moment (I don't work with eZ Publish in my day job)

I'd love peole to contribute/take it over/use the ideas:

https://github.com/stevoland/ez_sedit

The frontend is quite nice - the backend is a total hack + the inline attribute editing feature won't work.

Think it's compatible with 4.3/4.4.

Cheers

Friday 25 February 2011 4:35:34 am

I think i understand Paul, specially when you think about searching and things like that. i mean, is doable to edit an attribute and only one attribute, but from there, we have to think in how ez works in some aspects.

For example, versioning. should we create a new version for every attribute editing inline? for instance, article class. we have title, short-title, body, tags, image... ok. we want inline editing for all, but should we create a new version for one?

if so, how to proceed if two attrs are being edited at the same time? i mean, probably one of your editors takes only care about the body and other take care of the images. editor 1 wants to change body of the article. he hover the body, and start editing. 1 minute later, image editor wants to change the image. he hover the images and start the process...

actually ez publish warns you if the same object is being edited. should we do the same with inline attribute? should we tell the image editor "hey, wait until the content editor finish"?

Other thing to note is related to searching. Actually, many ez publish projects are leaving ezfind the fetch content operations, because you can make more flexible queries from there. but actually, for reindex the title of one of your articles you need to reindex the whole object. if i'm not wrong solr will permit attribute indexing, but do know if this is possible right now.

so, back to the example, if you edit title, short-title and all the others, we would need to republish thewhole object in order to be reindexed? If you don't do that, you will probably get search results having title or texting you typed previously and not the updated by this inline editing thing.

Even if you have delayingindexing enabled, you still need to republish the object in order to be indexed by the cron.. right?

So, yep, still doable and really cool to have it. just thinking about possible unwanted sideeffects :)

Friday 25 February 2011 7:26:11 am

well, i say Solr because i can't imagine a search module in ez without it :) but the thing is just the same for the standard ezsearchengine.

fortunately there are things that could help here. i mean, default version history limit is set to 10. that can be increased, but also it can increase the whole database size...

and my other worries it's about perfomance. Suppose you have lot of attribs in one case. suppose 30 maybe. for some of them you're probably using custom indexing capabilites... and even more, probably you can be using content -> publish -> after workflows.

my worry it's if wouldn't take too much time editing one attribute because of it...

while writing this i realized about workflows. would you execute that workflow for each attribute editing? and what about 'approving stuff'?

surely Paul can explain it much better, but i think things like this is what he was talking about :).

Sunday 27 February 2011 3:51:11 am

Whoa, quite a large discussion, that's great.

First, I think that the fact that we currently can't really edit one attribute only shouldn't be considered a problem. While it is true that under the hood, editing one attribute means editing the object, it is still possible to edit an attribute only, and not pass the others at all. So very pragmatically, yes, one attribute only can be edited.

I think we're getting very close from the proof-of-concept stage: yes, not everything has been addressed. Yes, there are many aspects to this (UI, permissions, ...). But we know:

• what we can apply this to: attribute_view_gui / content_view_gui
• what we need to target it at: content/edit, as if "Send for publishing" was clicked

Isn't that sufficient as of now ? This topic is so wide it would be a shame not to at least try ! I know for sure I'm interested in contributing, and that it would be a killer feature. My personal time is a bit limited between my three babies (my soon-to-be son, eZ Market, eZ Publish 4.5 beta), but hell it's cool !

Bertrand Dunogier
eZ Systems Engineering, Lyon
http://twitter.com/bdunogier
http://gplus.to/BertrandDunogier

Sunday 27 February 2011 7:34:59 am

As I've said, it's not easy, just possible and fun :-)

About versioning, well, I don't think we actually need drafts when doing frontend editing like this. Or do we ? One goal could be that such an interface will let you edit one (or more ?) attributes in an inline fashion. Either we create the edit interface the best we can, and deal with creating the version & publishing it in one go on the server side handler, or we use AJAX to create a real-draft, and are back to a close-to-standard workflow. About workflows, yes, interruptions of the publishing workflow are tough to answer. We need to look at the possibilities, the constraints, and the actual needs. But let's say this would apply to direct editings.

Now, another solution that could work: whenever node_view_gui / content_view_gui / attribute_view_gui are used, we know which node/object/attribute is viewed, and can therefore know which node/object/attribute could be edited from here. But when using attribute_view_gui, several attributes of the same object could be displayed on the same page. What about adding _ if edit permissions are there _ markup data that will let us scan the page for editable objects, and when asked (through a variant of ezwt ?) to switch to edit mode, buttons would be added (or maybe a side bar ?) that would popup an edit overlay for the edited object. Wouldn't that be sexy ? It ain't as seamless as swapping view with edit, but the display size between view & edit can be totally different, and it wouldn't work at all sometimes...

Bertrand Dunogier
eZ Systems Engineering, Lyon
http://twitter.com/bdunogier
http://gplus.to/BertrandDunogier

Sunday 27 February 2011 1:12:47 pm

As I've said, it's not easy, just possible and fun :-)

About versioning, well, I don't think we actually need drafts when doing frontend editing like this. Or do we ?

That's the question :). If not the thing could be easier, but if so, it's possible without doing it at object level?

What about adding _ if edit permissions are there _ markup data that will let us scan the page for editable objects, and when asked (through a variant of ezwt ?) to switch to edit mode, buttons would be added (or maybe a side bar ?) that would popup an edit overlay for the edited object. Wouldn't that be sexy ?

sure it would be sexy, but i would go even further. no need to click in anything. I think a mix between Eirik's idea and yours would it make even more sexy.

the markup will depend on permission, right, but i wasn't thinking in side bars nor ezwt. i'm more of the idea of this buttons can be show on hovering. and, well, as ez works now, if you have rigths to edit the object, you will have the rights to edit all the attributes of that object.

and yep, after an edit overlay different for each datatype could do the job.

first part could be like this, and, ok, if we choose not versioning can be doable setting the content for that specific contentobject attribute. if we need versioning thin is still doable, but i just worried about performance in terms of editing.

Cheers

Thursday 03 March 2011 10:46:22 am

@STEVO: Would you care to elaborate on how the extension should be set up, and how we can confirm that it works? I tried downloading it from github and putting it in extension/_sedit. I then enabled the extension globally, cleared the cache and tried logging into the frontend. However, all I can see is a blank button in the toolbar with the tooltip "Edit content inline".

BTW, this was done on a (fairly) fresh 4.4.0 installation with ezwebin.

Sincerely,

Eirik Alfstad Johansen
http://www.netmaking.no/

Thursday 03 March 2011 1:07:08 pm

Sorry - forgot to mention that the extension doesn't override attribute_view_gui and node_view_gui but adds new template functions that wrap them - so you'll currently have to do a search + replace throughout all relevant templates - ezwebin, ezflow, custom frontent templates.
Change attribute_view_gui to attribute_sedit_gui
Change node_view_gui to node_sedit_gui
Also there's a couple of regex search/replaces in /temp/regex.txt that should be used for full effect.
The toolbar button doesn't do anything yet.
Clear all caches etc then you should see divs as mentioned above wrapping content areas and rolling over them will reveal the icons.
Cheers