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
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
