About the default file structure: jQuery UI currently has a theme folder, with a folder in there according to the name of the theme. Inside that are .css files and another folder, called images. All images referenced within the css files are inside that folder.
So assuming that a plugin comes with a single theme, the file structure could look like this per convention: jquery-plugin * theme - jquery.plugin.css * images - imagefiles.png... * demo * docs * etc. - jquery.plugin.js - jquery.plugin.min.js - jquery.plugin.pack.js So, in this case with no dependencies, the meta file could look like this: { name: "jquery.plugin", author: "Author Author", version: "1.0" } About versioning: Should be always use full numbers? That is, 1.0.0 instead of 1.0? It certainly has advantages when listing various versions. Should file names have versions? The base folder? So far I'd prefer to have the version in the base folder that contains everything else, and within the actual plugin files, but not in the plugin file names. Jörn On Sun, Oct 5, 2008 at 5:23 PM, Ca-Phun Ung <[EMAIL PROTECTED]> wrote: > Exactly. Even on the rare occasion when someone uses a full url with http:// > it is pretty simple to just ignore those. > > On Sun, Oct 5, 2008 at 10:57 PM, Jörn Zaefferer > <[EMAIL PROTECTED]> wrote: >> >> That would simply assume that any URL within the CSS file is a >> relative URL, which seems to be a safe bet. Having absolute URLs in >> there doesn't make too much sense anyway, at least not in this >> context. >> >> Jörn >> >> On Sun, Oct 5, 2008 at 7:11 AM, Ca-Phun Ung <[EMAIL PROTECTED]> wrote: >> > Good stuff! One post from Jörn is better than a thousand from me, hehe >> > :) >> > I'd say however that even the /* [relative-url] */ marker is not >> > necessary >> > and just another chance for error. What you could do simply is find all >> > url(....) references and extract the necessary URL details within. It's >> > probably not as simple as that but you get the gist. :) >> > >> > On Sun, Oct 5, 2008 at 2:52 AM, Yehuda Katz <[EMAIL PROTECTED]> wrote: >> >> >> >> That sounds great. I would still want a cssDir and imagesDir in the >> >> json, >> >> so that I could simply use the last part of the relative URL marked >> >> with /* >> >> [relative-url] */ and know where the images actually were in the >> >> package. >> >> -- Yehuda >> >> >> >> On Sat, Oct 4, 2008 at 2:39 AM, Jörn Zaefferer >> >> <[EMAIL PROTECTED]> wrote: >> >>> >> >>> A token that a plugin user must replace isn't acceptable, as it defies >> >>> the drop-in nature of most plugins. But there are alternatives that >> >>> would allow Yehuda to automate replacing the relative directory URL >> >>> without anyone else having to modify the file. >> >>> >> >>> Something like this: >> >>> background-image: url(../img/bla.png) /* [relative-url] */ >> >>> >> >>> Writing a script that looks for these inline comments and modifies the >> >>> content accordingly wouldn't be any harder then the %imagePath% token. >> >>> >> >>> In any case, we should define a convention for packaging resources, so >> >>> that a plugin author can stick with the convention, without having to >> >>> specify the metadata. Based on that convention and inline comments a >> >>> plugin user could automate moving resources to project-specific >> >>> folders. >> >>> >> >>> About the other metadata.json elements: >> >>> >> >>> How about keeping plugin names in sync with file names? jquery.tabs.js >> >>> -> jquery.tabs; ui.core.js -> ui.core >> >>> >> >>> What about versioned depenendencies? Dependency to a certain jQuery >> >>> version? >> >>> >> >>> So far plugins are always packaged into a single file, something like >> >>> utility.tabs.jquery isn't in wide use. I don't see why that should be >> >>> changed. >> >>> >> >>> So, to summarize: >> >>> >> >>> { >> >>> name: "jquery.tabs", >> >>> author: "Yehuda Katz", >> >>> version: "1.0" >> >>> dependencies: { >> >>> "ui.core": "1.6", >> >>> "ui.mouse": "1.6" >> >>> } >> >>> } >> >>> >> >>> Jörn >> >>> >> >>> On Sat, Oct 4, 2008 at 9:49 AM, Ca-Phun Ung <[EMAIL PROTECTED]> >> >>> wrote: >> >>> > I understand what you are saying - and believe me I have much >> >>> > experience >> >>> > with "real-projects" that have their separate image/css/javascript >> >>> > folders >> >>> > set in a certain way. What I'm trying to impart is the idea of >> >>> > de-coupling >> >>> > so that plugin assets are independent of whatever system it is >> >>> > placed >> >>> > into. >> >>> > By adding a %imgDir% token to CSS we're already assuming developers >> >>> > wants to >> >>> > change CSS files whereas some might quite happily use the plugin >> >>> > as-is, >> >>> > placing it inside a dedicated plugins sub-folder and link to the >> >>> > plugin >> >>> > css >> >>> > files directly. >> >>> > The point is you don't have to map the structure implanted inside a >> >>> > plugin >> >>> > to the structure on your system. They could live quite happily >> >>> > together. >> >>> > What we're dealing with here is a matter of aesthetics which is not >> >>> > something you could get right for everyone. >> >>> > If it is absolutely essential that all images/css are placed inside >> >>> > that >> >>> > specified by the system then I think the automated tool could quite >> >>> > easily >> >>> > handle this. It should be quite simple to write a CSS parser in Ruby >> >>> > or >> >>> > even >> >>> > a simple regex to replace the combination found inside url(...) so >> >>> > it >> >>> > replaces anything before the image filename with whatever folder >> >>> > structure >> >>> > the system chooses. >> >>> > On Sat, Oct 4, 2008 at 3:10 PM, Yehuda Katz <[EMAIL PROTECTED]> >> >>> > wrote: >> >>> >> >> >>> >> People who download plugins today have to go modify CSS files to >> >>> >> make >> >>> >> them >> >>> >> match their existing directory structure. I've had to contend with >> >>> >> this more >> >>> >> than once with the tabs plugin, including having to figure out the >> >>> >> issue in >> >>> >> the first place. Typical downloaders could use the find/replace >> >>> >> feature of >> >>> >> their editors to quickly set up the CSS the way it belongs in their >> >>> >> project, >> >>> >> and we could document this, instead of developers, every time, >> >>> >> having >> >>> >> to go >> >>> >> into the bundled CSS to figure out the expectations of the plugin. >> >>> >> We could potentially also set up packages.jquery.com to >> >>> >> automatically >> >>> >> replace the token for a non-tokenized version (although, again, I >> >>> >> think >> >>> >> making assumptions about people's directory structures doesn't map >> >>> >> well onto >> >>> >> real-world projects). >> >>> >> -- Yehuda >> >>> >> >> >>> >> On Fri, Oct 3, 2008 at 9:33 PM, Ca-Phun Ung <[EMAIL PROTECTED]> >> >>> >> wrote: >> >>> >>> >> >>> >>> A few more potential issues with the %imgDir% token are: >> >>> >>> 1. Plugin developers need to remember to add the token back in >> >>> >>> every >> >>> >>> time >> >>> >>> they package the plugin for release. >> >>> >>> 2. Those who simply download plugins without an automated tool >> >>> >>> will >> >>> >>> have >> >>> >>> a problem with this token. >> >>> >>> 3. If we're saying that this is a separate repository under >> >>> >>> packages.jquery.com, we may come into sync'ing issues as plugin >> >>> >>> developers >> >>> >>> have to upload their plugins twice. One version with the token and >> >>> >>> another >> >>> >>> without. >> >>> >>> On Sat, Oct 4, 2008 at 12:05 PM, Ca-Phun Ung <[EMAIL PROTECTED]> >> >>> >>> wrote: >> >>> >>>> >> >>> >>>> But if we don't touch CSS and image locations we're not assuming >> >>> >>>> anything - the plugin developer should make this decision and not >> >>> >>>> the >> >>> >>>> automation tool. The automation tool should simply copy over the >> >>> >>>> plugin as >> >>> >>>> is and use the metadata.json to determine what is needed for >> >>> >>>> installation. >> >>> >>>> If we start dealing with image and CSS re-location it will make >> >>> >>>> plugin >> >>> >>>> maintenance more difficult, i.e. what happens if you decide to >> >>> >>>> delete the >> >>> >>>> plugin? >> >>> >>>> >> >>> >>>> >> >>> >>>> On Sat, Oct 4, 2008 at 4:34 AM, Yehuda Katz <[EMAIL PROTECTED]> >> >>> >>>> wrote: >> >>> >>>>> >> >>> >>>>> The problem is that you *can't* assume that the img folder >> >>> >>>>> remains >> >>> >>>>> relative to the css folder. People are putting jQuery inside of >> >>> >>>>> other >> >>> >>>>> directory structure (like Rails or Merb) which have their own >> >>> >>>>> conventions, >> >>> >>>>> and then it's up to the individual developer to figure out how >> >>> >>>>> to >> >>> >>>>> modify the >> >>> >>>>> relative paths. >> >>> >>>>> I'd like to be able to automate the installation of jQuery >> >>> >>>>> plugins, >> >>> >>>>> which means not having to figure this out manually. >> >>> >>>>> -- Yehuda >> >>> >>>>> >> >>> >>>>> On Fri, Oct 3, 2008 at 8:54 AM, Ca-Phun Ung >> >>> >>>>> <[EMAIL PROTECTED]> >> >>> >>>>> wrote: >> >>> >>>>>> >> >>> >>>>>> Hi Yehuda, >> >>> >>>>>> Interesting proposal. >> >>> >>>>>> A note on CSS images. I'm not sure the %imageDir% token will be >> >>> >>>>>> of >> >>> >>>>>> any >> >>> >>>>>> use in CSS because CSS is capable of locating images relative >> >>> >>>>>> to >> >>> >>>>>> itself. >> >>> >>>>>> i.e. if we have a structure like >> >>> >>>>>> /assets >> >>> >>>>>> -- /css/style.css >> >>> >>>>>> -- /img/logo.png >> >>> >>>>>> Then as long as the img folder remains relative to the css >> >>> >>>>>> folder, >> >>> >>>>>> whereever it is copied the following will always hold true: >> >>> >>>>>> _style.css_ >> >>> >>>>>> div#logo { >> >>> >>>>>> background: url( ../img/logo.png ) no-repeat; >> >>> >>>>>> } >> >>> >>>>>> >> >>> >>>>>> >> >>> >>>>>> On Fri, Oct 3, 2008 at 2:31 PM, Yehuda Katz <[EMAIL PROTECTED]> >> >>> >>>>>> wrote: >> >>> >>>>>>> >> >>> >>>>>>> For a while, I've been trying to make it possible to build a >> >>> >>>>>>> system >> >>> >>>>>>> to automatically install jQuery plugins into an application. >> >>> >>>>>>> In >> >>> >>>>>>> particular, >> >>> >>>>>>> I've wanted to be able to let Merb (a Ruby web framework I >> >>> >>>>>>> maintain >> >>> >>>>>>> -- http://merbivore.com/) install jQuery plugins simply and >> >>> >>>>>>> easily. >> >>> >>>>>>> There are a few problems I needed to see solved: >> >>> >>>>>>> >> >>> >>>>>>> A way for package authors to describe the locations of the >> >>> >>>>>>> javascript >> >>> >>>>>>> files, the CSS files, and any images >> >>> >>>>>>> A way for package authors to declare required dependencies >> >>> >>>>>>> A way to write CSS files that don't need to provide explicit >> >>> >>>>>>> image >> >>> >>>>>>> paths >> >>> >>>>>>> >> >>> >>>>>>> I want to propose a packaging format that plugin authors can >> >>> >>>>>>> use. >> >>> >>>>>>> To >> >>> >>>>>>> get the ball rolling, I'm proposing a JSON file called >> >>> >>>>>>> metadata.json: >> >>> >>>>>>> { >> >>> >>>>>>> "name": "tabs.jquery", >> >>> >>>>>>> "author": "Yehuda Katz", >> >>> >>>>>>> "dependencies": [ >> >>> >>>>>>> "core.ui.jquery", >> >>> >>>>>>> "mouse.ui.jquery" >> >>> >>>>>>> ], >> >>> >>>>>>> "javascript": [ >> >>> >>>>>>> "lib/utility.tabs.jquery", >> >>> >>>>>>> "lib/tabs.jquery", >> >>> >>>>>>> ], >> >>> >>>>>>> "cssDir": "css", >> >>> >>>>>>> "imageDir": "images" >> >>> >>>>>>> } >> >>> >>>>>>> Additionally, I'd like to propose that CSS files containing >> >>> >>>>>>> image >> >>> >>>>>>> paths use the token %imageDir% to refer to the directory where >> >>> >>>>>>> the images >> >>> >>>>>>> will be placed. This will allow automated tools (or even users >> >>> >>>>>>> themselves) >> >>> >>>>>>> to quickly modify CSS files with the correct relative (or >> >>> >>>>>>> absolute) path. >> >>> >>>>>>> Does this stuff make sense? People seemed to be, in general, >> >>> >>>>>>> in >> >>> >>>>>>> favor >> >>> >>>>>>> of a more consistent package format, so I thought I'd get the >> >>> >>>>>>> ball rolling >> >>> >>>>>>> here. >> >>> >>>>>>> -- >> >>> >>>>>>> Yehuda Katz >> >>> >>>>>>> Developer | Engine Yard >> >>> >>>>>>> (ph) 718.877.1325 >> >>> >>>>>>> >> >>> >>>>>>> >> >>> >>>>>> >> >>> >>>>>> >> >>> >>>>>> >> >>> >>>>>> -- >> >>> >>>>>> Ca-Phun Ung >> >>> >>>>>> + Yelotofu <http://yelotofu.com> >> >>> >>>>>> + css, django, hongkong, html, javascript, php >> >>> >>>>>> >> >>> >>>>>> >> >>> >>>>> >> >>> >>>>> >> >>> >>>>> >> >>> >>>>> -- >> >>> >>>>> Yehuda Katz >> >>> >>>>> Developer | Engine Yard >> >>> >>>>> (ph) 718.877.1325 >> >>> >>>>> >> >>> >>>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> -- >> >>> >>>> Ca-Phun Ung >> >>> >>>> + Yelotofu <http://yelotofu.com> >> >>> >>>> + css, django, hongkong, html, javascript, php >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> -- >> >>> >>> Ca-Phun Ung >> >>> >>> + Yelotofu <http://yelotofu.com> >> >>> >>> + css, django, hongkong, html, javascript, php >> >>> >>> >> >>> >>> >> >>> >> >> >>> >> >> >>> >> >> >>> >> -- >> >>> >> Yehuda Katz >> >>> >> Developer | Engine Yard >> >>> >> (ph) 718.877.1325 >> >>> >> >> >>> >> >> >>> > >> >>> > >> >>> > >> >>> > -- >> >>> > Ca-Phun Ung >> >>> > + http://yelotofu.com >> >>> > + css, django, hongkong, html, javascript, php >> >>> > >> >>> > > >> >>> > >> >>> >> >>> >> >> >> >> >> >> >> >> -- >> >> Yehuda Katz >> >> Developer | Engine Yard >> >> (ph) 718.877.1325 >> >> >> >> >> > >> > >> > >> > -- >> > Ca-Phun Ung >> > + http://yelotofu.com >> > + css, django, hongkong, html, javascript, php >> > >> > > >> > >> >> > > > > -- > Ca-Phun Ung > + http://yelotofu.com > + css, django, hongkong, html, javascript, php > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~----------~----~----~----~------~----~------~--~---