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

[Michael Wechner]

Guillaume Déflache wrote:
>
>>
>> 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.

you can write a test within your custom project and also a test within 
the usecase-realm using the src property (I think
such a test does not exist yet)



>
>
>>>> 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, ...)


agreed. Let me think about that some more ....



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

the borders are not always clear
>
>
>> 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, 

people just do it, trust me ;-)

For example XSLTs (or Jelly) often contain content which is not 
editable, but at some point people want to change it



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

agreed

Cheers

Michi
>
>
>>> (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.