I also vote for folder-level versioning, it makes for a one spot
change to update versions manually. As for plugins, I don't suspect
that the authors will be as strict with version numbering as the core
should be. My pattern is like this though:
(if(Breaks API)++).(if(Adds minor features and doesn
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 th
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 curren
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
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 sa
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
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
probab
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 PROTECTE
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(.
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.
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
It just doesn't work that way in real life. Real projects have separate
directories with images, css, and javascript directories, that at least in
my experience, don't usually comply with the directory structure assumed by
the plugin creator.
Consider, for instance, the UI plugins. They have a them
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
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
de
Ideally, plugins.jquery.com would handle putting the packages in the right
place (i.e. packages would get named autocomplete-1.0.5 in some central
place, which would also store the list of all the meta.jsons).
-- Yehuda
On Fri, Oct 3, 2008 at 2:31 PM, Brandon Aaron <[EMAIL PROTECTED]>wrote:
> I'm
I'm all for this. Seems like we'd want a standard repository/location to
store these "packaged" plugins with the %imgDir% applied, etc. Maybe on
plugins.jquery.com or maybe on a new sub-domain like
packages.jquery.comthat just follows a particular directory structure
and naming scheme.
--
Brandon A
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
p
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
18 matches
Mail list logo
