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