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