[Yanel-dev] Re: [Yanel-commits] rev 48566 - public/yanel/trunk/src/resources/file/src/java/org/wyona/yanel/impl/resources/node

[Guillaume Déflache]

Michael Wechner schrieb:
> Guillaume Déflache wrote:
>> Hi!
>>
>> Michael Wechner schrieb:
>>> Dear Guillaume
>>>
>>> As discussed before lets please discuss such changes beforehand:
>>>
>>> - Explain what you intend to do and how you want to use this
>>
>> I already explain the intent months ago in "[Yanel-dev] separating 
>> content from application code &  configuration (or getting rid of 
>> "app" directory in repository e.g. data/app/)" 
>> http://lists.wyona.org/pipermail/yanel-development/2009-November/004154.html 
>> on which I had no feedback.
> 
> just remind people once again

OK.


>> The change compared to that message is that I found an even simpler 
>> solution for the "3.2)" point there that is fully backward-compatible 
>> and IMHO does no harm, so I just committed "out of enthousiasm", sorry...
>> Maybe I should reply to my own message and explain this new solution 
>> there?
> 
> please do

I link to this thread from there instead as the discussion continues here.

> 
>>> - Make examples/document it
>>
>> I will be glad to do that once we agree on the details like the name 
>> of the RC property.
>> BTW I already tested that on the project I am currently starting, 
>> works great.
>> We can probably illustrate it on any public realm that uses a 
>> "data/app"-like directory, and maybe add a HTTPUnit or Canoo test for 
>> that while we are at it.
> 
> yes, you should do that

As agreed with Michi, he will revert the change in Yanel and I will add 
the modified file resource-type in my own project, so for now I can not 
write a public test specifically for that feature.


>>> Maybe there are other possibilities to acomplish what you  want to 
>>> acomplish.
>>
>> Maybe, but nobody stepped up to suggest any so far,
> 
> Well, I think it's better to use a protocol:
> 
> http://documentation.yanel.wyona.org/wiki/wiki/Unstructured%20Points
> 
> e.g.
> 
> src="yanelrepo:REALM_ID:REPO_ID:/index.html"
> 
> and in your particular case
> 
> src="yanelrepo::app:/index.html"
> 
> WDYT?

That's also what I initially had in mind for 3.2) but there are problems 
with this approach:
- all protocols do not resolve any URL to a writable resource:
   - that may mislead people into thinking any protocol may be used
   - one would have to special-case on some protocols, and it is not 
clear to me what the ramifications could be
- it will only work for one file per RC: as one needs a full URL to 
resolve it to something, one cannot for example easily map 
http://localhost:8080/yanel/my-realm/app/** to $MY_REALM_DIR/htdocs/** 
which is what I'd like to do for all static content (CSS, JS, ...)


>> and I did not want to start a project with a "data/app" directory ever 
>> again, because we all know it cause lots of deployment problems
> 
> you mean because of the CHANGE_LOG?

Among others outlined in 
http://lists.wyona.org/pipermail/yanel-development/2009-November/004154.html 
yes.

Generally I would like to really be able to switch content repositories 
(for deployment in test or production environments) only by editing the 
corresponding repository configuration file, and without copying files.
If neither application code nor additional configuration files are in 
the content repository, this should be doable.


> If you have files within a separate repository, you will still have to 
> synchronize these repositories and chances
> are there that people do make changes on the productive environment. So 

Application code files should not need to be changed on the production 
environment, so at least moving them away should reduce the need to sync 
to only real content (and configuration if we do not decide to move it 
away as well).


> I don't think the problems
> will go away completely, but I agree it will make it easier

There are probably some other kinds of files I did not think about, but 
I really think taking care of the current large majority of misplaced 
files will already help a lot.


>> (as you reminded me lately when I introduced a "data/admin" directory 
>> for storing mockup XHTML pages).
> 
> I think that's a different case

I think it may be solved by the same enhancements, but I guess it's a 
matter of POV.