Hello Fraser,

I love the ideas you share here in this thread.

I write this evening with a few ideas, examples and suggestions ...

We recently created a module view which provided this exact feature (for a different end purpose) within the admin, "Display browse to select node / node subtree if requested directly or no nodeID is provided (fallback just in case ... and when that case does happen handle it elegantly in the same way)". It even remembers these browse parameters and reuses them if they are not provided (which we do not by default to always rely on this feature).

https://github.com/brookinsconsulting/bcimagealias/blob/master/modules/bcimagealias/create.php#L140 

https://github.com/brookinsconsulting/bcimagealias/blob/master/modules/bcimagealias/create.php#L159

I would imagine it would be trivial to create a copy of the default content module (renamed module dir required here) into a new extension and customize the related module view PHP to better suit your needs; perhaps using the above example custom use to provide a similar feature in your customized copy of the .. ah yes you would be focused on customizing a copy of the action module view.

https://github.com/ezsystems/ezpublish/blob/master/kernel/content/action.php#L53

Creating such modified copy of the content module (renamed) is so pain free and simple, any one can do it in 3 minutes flat.

Copy the module dir from kernel into new extension's module directory, rename copied directory content to any other text name that is not reserved or publicly used already or generic (this leads to conflicts when generics were used in the past, now a two to three letter prefix is strongly recommended as we do which always ensures against conflicts), you must rename the module dir because it will conflict with the default otherwise, you must also edit and rename the module itself with the module dir's module.php file as shown here https://github.com/ezsystems/ezpublish/blob/master/kernel/content/module.php#L9

Also in your code remember to pass the parameter 'start_node' => $currentNodeID to the 'eZContentBrowse::browse' call in your code if you wish to use say the current location / node subtree as the start node when the content browse dialog is displayed. Then when you return back to the module view after content browse you will have a nodeID you can use in you create your new node and redirect to edit it normally. Remember to add the corresponding module.ini settings for the custom module (required) and any other extension configuration settings into your custom extension (as needed or desired), activate extension in ini settings, clear caches and you should be able to then call and use the module view normally.

Then it should be trivial to modify the related php required to provide the feature when called. Then you will want/need (in most use cases) to override key admin templates (sorry i don't' recall quickly offhand) to use a the url of the custom module view in the form action url parameter within the template html.

This ensures that requests to this functionality are directed to your custom copy of the module view for all of this forms requests (unfortunate side affect of the nature of this system and this solution) including the one your customizing the execution for ... and provided you copy the whole module (only way we support modified copies of kernel modules) the rest of the other uses of this form are also retained using the same code as the current kernel release (limitations of modified copies of default modules and views*; most users only rarely find need to upgrade these kinds of solutions in practice and when they do if they have any skills with diff tools then they can easily upgrade the custom module php and retain your previous modifications.

Again it's a bit of a rant but if module views could be overridden by extensions we might not need to maintain a modified copy at all (that's our dream for the future at least ... will you dream with us?) 

But until then this functionality by design is binds the developers hands rather tightly to the work required to do the job the right way.

Notice I will not recommend patching the kernel here as that is not a solution what so ever, it's an excuse, common among those who are short signted, ignorant, and not delivering supportable solutions instead since they refuse to learn they just make edits through large parts of their customers project, leaving the work product resulting without using extensions -at all- and worse huge parts of the kernel have been modified without use of version control. Worse than lazy, incompetent ... bordering on fraud.

I see this very situation regularly, to this day and it saddens me greatly knowing the customer was abused, robbed blind, if you will, from the long term value, their investment of capital, they were certainly seeking in the solution they were empowering the clueless developer to produce on their behalf. Any long term value in these kinds of project results is gone before you ever usually come to learn the truth of what they had done to the customer by someone they had trusted to help them not harm them.

In this way what you do is very stable and supportable as it is based on core kernel code (using the most mature module I'm aware of .. content) so very stable (your changes aside merely unproven) and it's an extension so it should be very pleasant to create and maintain.

I'm curious your thoughts folks. What do you think of these thoughts and ideas?

Is any of the above helpful to anyone ... ?

I do hope this helps ...

Cheers,

Heath

Modified on Friday 13 January 2012 8:17:40 am by Heath