Forwarding to component owner for consideration.

Forwarding to component owner for consideration.

Hi,
Thanks for the post. Yes we can look into exposing a per class (hierarchy) prefix.

Regards,
Satyen

This ticket was imported from Source Forge.

Orginially submitted by: mingfai

Marking 3.NEXT, to isolate Beta1 critical bugs.

I'm also running into similar situation where this would be extremely useful to configure the classNamePrefix per Widget sub-class. A great thing to consider when you guys start the Widget overhaul.

Starting to look into the implementation. Before I jump in and start changing things, wanted to confirm the use case:

The 2 pieces of the class name that are currently not directly configurable per instance are the "yui" and "<widgetname>" [ yui-<widgetname>-xxxx ]

a). "yui" can be configured for the YUI instance, but not per widget instance (as mingfai indicates).
b). "<widgetname>" is derived from the NAME property of the instance being created, so sub-classes inherently modify this part of the class name.

1). Is it just the "yui" you'd like to see configurable per instance?

So for example, you could generate mylibrary-overlay-xxxx for your library Overlay, as opposed to yui-overlay-xxxx

But if MyCustomOverlay extends Overlay, the Base development pattern of defining MyCustomOverlay.NAME = "myCustomOverlay", is sufficient to generate

mylibrary-mycustomoverlay-xxxx, or,
yui-mycustomoverlay-xxxx

2). Or do you need the ability to replace the use of "yui-<widgetname>" in it's entirety, with something custom, wherever widgetInstance.getClassName("xxxx") is used?

mylibrary-someOtherStringWhichIsNotTheWidgetName-xxxx

Hey Eric, haven't heard back from mingfai as to my use case question. Would you have any input on your requirements before I start implementing something?

Satyen,

I was looking at this from a sub-classing, Y.extend perspective. I would like to be able to "own" a Widget's CSS class.

e.g.

If I wanted to extend Y.Overlay (yui-overlay) to create my own Dialog subclass, Y.EDF.Dialog, I would like "edf-dialog" to be the CSS classname.

I'm not worried about configuring the Widget sub-class' CSS classnames per instance; I feel that is a bad idea. I would like to have to ability to override the CSS prefix (i.e. replace "yui-" with "edf-") when I'm subclassing a Widget.

Thanks for the input.

So, if I understand correctly, the core use case is that you'd like to have a YUI Dialog and an EDF Dialog in the same sandbox?

The YUI Dialog uses yui-dialog-xxxx and ships with CSS targetting these "yui-dialog-xxxx" class names.
The EDF Dialog uses edf-dialog-xxxx and ships with CSS targetting the "edf-dialog-xxxx" class names.

If that accurate, I think events are also impacted in the same way, and which is where I'm thinking that it's probably better to leverage the .NAME property which already exists to distinguish one class from another for the purposes of both CSS and events.

e.g.

It seems like Y.EDF.Dialog.NAME = "edfDialog", to differentiate it from Y.Dialog.NAME = "dialog".

So that, for example, the show event fired by EDF Dialogs are, by default, "edfdialog:show" events as opposed to "dialog:show" events (in the same way that "menu:show", "treeview:show" are also different from "dialog:show").

And in which case, the EDF Dialog uses yui-edfdialog-xxxx, to differentiate it from yui-dialog-xxxx.

Is that not an acceptable class name for the EDF dialog, because of the "yui-"?

Satyen,

I was thinking about this slightly differently (assuming I'm understanding what you're saying).

Yes, I'm talking about one YUI instance/sandbox.

Now say I'm writing working on an application, and I decided to write a Custom Module, a Dialog module, which I plan to use in this application and across other applications as it's reusable. When writing this module, I make a decision to start by extending the Y.Overlay module, as my Dialog module is an Overlay plus more. I make a decision to namespace my Dialog module under the EDF namespace; making the Class accessible via Y.EDF.Dialog. I'd naturally set this module's NAME property to "dialog" as no other Dialog module exists in YUI or my custom mode. Now getting to my initial point: When adding style to my new Dialog module, I would like to be able to control the CSS classname prefix, as this is my module and is not a part of YUI core. I feel it would be useful to be able to set the CSS classname prefix on my module I develop as a module developer. Naturally I'd want this prefix to be "edf-" in this case because by convention I'm namespacing my Custom Modules under the EDF namespace.

I think this request is more for clarity and segmenting. It communicates that this module isn't part of YUI-core, but rather, part of the EDF package of modules. When sharing my custom modules in the Gallery with other developers, their CSS code for my custom modules would be nicely segmented from other develop's modules and the YUI-core modules.

So, I'm not saying that it's not acceptable to have a "yui-" CSS classname prefix for all modules, it certainly is; but, I'm not sure if it's the best approach for extensibility.

What's the reasoning for the current setup?

And what advantage is there to setting the CSS classname prefix globally, on the YUI instance?

Let me start by saying I agree that the need to provide a way to customize the prefix per instance is a valid one.

I'm really just debating whether it should be "yui-edfoverlay" which can be done based on the current NAME support or "edf-overlay" which would require additional switches.

>> What's the reasoning for the current setup?

NAME is intended to serve as the identifier for a particular class in the system.

Hence the convention (the package part of which I just realized is not part of the API docs) has been...

Y.MyPackage.MyClass.NAME = "myPackageMyClass";

So that NAME is able to differentiate "Y.EDF.Dialog" from "Y.Dialog" (when one exists):

Y.EDF.Dialog.NAME = "edfDialog";
Y.Dialog.NAME = "dialog";

NAME is currently used to drive...

1) event prefixes:

"edfDialog:show" would be the event fired when Y.EDF.Dialog's are shown.
"dialog:show" is the event fired when Y.Dialog's are shown

2) css class name generation:

"yui-edfdialog-hidden" would be the class name used to mark a hidden Y.EDF.Dialog
"yui-dialog-hidden" would be the class name used to mark hidden Y.Dialog's

And could be used in future to reference classes by string key in some central registry for example.

>> And what advantage is there to setting the CSS classname prefix globally, on the YUI instance?

Good question. The goal behind this switch was to allow for folks who really don't want the "yui-" prefix at all in their instance. However I agree it's use is limited in components which bundle CSS (until we have a build/tool to modify the bundled css), since it needs the CSS to be updated to match. It's useful to provide the flexibility in ClassNameManager for folks building applications on top of the lower levels (say a basic static page on top of Node/Event).

That said, I can understand the appeal for custom component developers of "edf-dialog-hidden" over "yui-edfdialog-hidden" (although functionally equivalent - serve the purpose of distinguising Y.EDF.Dialog from Y.Dialog).

I can look into adding a couple of prototype properties for 3.1 - "cssPrefix", "eventPrefix" to map to the current uses of NAME, allowing the component developer control over these uses (they'd default to the current NAME based implementations), but I'm thinking the general idea of a package name maybe worth evaluating for a future release, for custom component development (for example so you could listen for "edf:*:init" events - need to think through that a little more).

Does that help?

Added support to allow custom component developers to define their own CSS class name and event prefixes. Fixes #2430621
View Commit: