Looking at tags in subversion, 1.x is used for major releases, 1.x.x
for minor, and in contrast to what I was worrying about, the order
doesn't get messed up. So we can just stick with that.
I'll try to modify the plugins/build.xml ant script to put the version
into the folder it creates inside the zip file. Otherwise we need some
refactoring, moving css and image files to theme and theme/images.
Jörn
On Mon, Oct 6, 2008 at 1:22 PM, Ca-Phun Ung <[EMAIL PROTECTED]> wrote:
>
>
> On Sun, Oct 5, 2008 at 11:37 PM, Jörn Zaefferer
> <[EMAIL PROTECTED]> wrote:
>
>>
>> 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.
>
> Sounds like a good idea but I'm not sure what the convention is currently
> with jQuery and UI. Might be best to follow existing convention?
>
>>
>> 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.
>
> I agree. We should not add version numbers to 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
>> >
>> > >
>> >
>>
>>
>
>
>
> --
> 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
-~----------~----~----~----~------~----~------~--~---
