settings to kill from pathauto
If you haven't seen it in it's full glory yet, look at http://drupal.org/node/189459
It's too big. Great. What can we do to slim it down and make it more useful?
- Create separate bulk generate page
- Use progressive disclosure for pattern settings
- Make tokens easier to find/add
- Create a new "Pathauto Advanced" module and
- Move the entire punctuation settings to it
- Move most? All? of the "General settings" to it. The only thing I don't think could go into that separate module is the "Update action:"
For anyone who uses these punctuation/general settings would you be upset if you had to enable the "Pathauto Advanced" module to get them?
Is there anything else that could be moved to the Advanced module?
Anything else that could be done to "slim down" that page?
Groups:
Login to post comments
Bulk updates separate // transliteration&simplification
First of all:
I'd extract the bulk updates from Pathauto and put it into a separate Bulk update module.
This is some special task and (i hope i'm right) parts of those processes (iteration, cron, ...) aren't needed by pathauto in regular usage.
Second:
The whole transliteration / simplification thing is putting a lot of complexity in.
How about separating it also from pathauto and put the complexity into another tab or even submodule.
How about introducing a Textfield to enter the punctuation replacement rules/dictionnary (instead of dropdowns?) (btw: is there a hook to act in this domain extensible? :-) )
Indeed when using unicode chars, the predefined element list is by far not all "punctuation" characters.
I'm thinking also about separating the content type specific fields completely - somehow.
at least the token lookup list should be redesigned. An ajax thing works pretty well but what about non-ajax fallback?...
What about some rule manager separated to add rules for a more generic approach instead of "do it all with one single page? ;-)
But possibly we should think a whole lot more before changing everything! I'd vote for a very advise process of change regarding real long term background..
Thanks for this great thing - Miro
thanks for the feedback
In response to your questions - there is an extensible way of adding punctuation in 6.x-2.x-dev (which is where all of these changes would happen anyway). That method is the transliteration module. The punctuation characters are just those defined in ASCII 128.
--
Growing Venture Solutions | Drupal Dashboard | Learn more about Drupal - buy a Drupal Book
alternate design
Greggles..
What if you turn pathautos core design into a generic framework/api for automated path generation with hooks only -- possibly with well default actions...
Where you put (as never in question till now) bulk processes completely outside
But you put all advanced controllable things (content type specific settings) into a submodule and also the transliteration (simplifyed)..
Indeed this is in complete contrast to your and others thoughts. This time - when you disable transliteration, it won't do no more transliteration (or internal generally simplified).
Thinking about extensibility and beauty in design, this sounds much more conceptually correct to me..
I personally don't like tools which act based on own introduced configuration values -- which i possibly can't controle.. The strict design "module" and "UI" i think is fine. But the design "module with trivial UI internally interpreting extended configuration" with separate "extended UI" is a bit odd...
You possibly should then put the whole UI out? (sounds odd too)
This whole talk is very fundamental about module design. The only really clear point is bulk topic to me and i'd very like to understand the full argumentation for your decision of any other change :-)
Thanks for any further sharing of thoughts.
some inspiration
I'm not sure I entirely understand your feedback, but here's an attempt at a response - if I miss something please clarify.
My inspiration for having the module respect variables that are not presented in the normal UI is from Firefox. Type about:config into the URL bar and you will see the thousands of configuration options which are buried deep in the code. Many extensions to firefox are simply a way to expose the variables that are actually defined and used inside the core of Firefox.
Another alternative is to make Pathauto more flexible - as you say - so that it has a very small core but is extensible via some hooks and then for every setting we remove from the current pathauto we implement that in a separate module that interacts with the core via a hook. As you point out, that is a more common approach to this problem and a more Drupalish solution and may ultimately prove to be the best way to do this.
I don't think that Pathauto should be a "core with hooks only" but I can certainly see it being a "core with sensible defaults and ONLY the most common use cases covered with hooks for the rest." That could work.
--
Growing Venture Solutions | Drupal Dashboard | Learn more about Drupal - buy a Drupal Book
configurability vs extensibility
Right, i see your argumentation and i see the common approach as firefox does.
And i think your understanding of my words was correct.
However, to combine both paradigms "just perfectly" isn't trivial by design.
Providing internal default action or configurable internal mechanisms and additional hooks could result in internal mechanisms which we're e.g. unable to "replace" (rewrite, redefine) and so concurring with extensibility...
Also if we're installing some very advanced module to implement transliteration (which possibly could REPLACE(?) complete internal behaviour, depending on concept behind) would irritate the user to see no more having the trivial configurable options to work ;-)
Design in this case is a pretty advanced task.
But looks like you have some clear understanding of designing it right and i love to see you improving it just perfectly .-)
tabs
Whether you go for a pathauto advanced or not, the punctuation settings could easily go to a tab.
Here's a list of stuff I think could move to 'advanced'
verbose
upper/lower case (who likes upper case URLs? not me)
maximums
transliteration
strings to remove
bulk updates
punctuation
Stuff to keep in the basic module:
separator
update action
all the settings for various objects
If you /do/ move to a basic + advanced module set up, then obviously it'd be nice to be able to enable the advanced module, change the settings, and then switch it off again but have those settings persist - a bit like you can do with Views UI. Should only be the interface to these variables that changes rather than the actual behaviour (except maybe bulk updates, which if it's any code weight, could live in a third module).
still working after disabling the UI
Not everyone agrees with this point, but I certainly do.
Thanks for your feedback. At least so far this kind of split doesn't appear to be too controversial so we should be able to make some progress.
--
Growing Venture Solutions | Drupal Dashboard | Learn more about Drupal - buy a Drupal Book