[Yanel-dev] organization of data

Evaldas Taroza etaroza at optaros.com
Thu Feb 28 17:31:24 CET 2008



simon litwan wrote:
> Evaldas Taroza schrieb:
>>
>>
>> simon litwan wrote:
>>> Josias Thöny schrieb:
>>>> Evaldas Taroza wrote:
>>>>>
>>>>>
>>>>> simon litwan wrote:
>>>>>>
>>>>>>> which lets you programmatically  access htdosc/yanel-htodcs.
>>>>>>>
>>>>>>> then we could introduce a kind a protocol in the rc. e.g. 
>>>>>>> htdocs:// resp. yanelhtdocs://
>>>>>>>
>>>>>>>      <view id="tablelist" type="jelly">
>>>>>>>        <xslt>/xslt/usecase.xsl</xslt>
>>>>>>>        <template>htdocs://create-tablelist-shortcut.jelly</template>
>>>>>>>        <mime-type>text/html</mime-type>
>>>>>>>      </view>
>>>>>>>
>>>>>>> this would use the jelly provided by the resource via htdocs.
>>>>>>> one could overwrite the jelly by omitting the protocol and point 
>>>>>>> to a jelly in the realms data repository.
>>>>>>>
>>>>>>> BTW:
>>>>>>> i think if the method public InputStream getHtdocs(String path) 
>>>>>>> would access the data via package resolving we would go a step 
>>>>>>> forward to provide resource-types as packages (which i consider 
>>>>>>> very important.)
>>>>>> i've implemented two new resourceResolver. one with the scheme 
>>>>>> "resourcehtdocs:" which access files within the resource-types 
>>>>>> htdocs directory and an other one with the scheme 
>>>>>> "resourceyanelhtdocs:" which access files within the 
>>>>>> resource-types yanel-htdocs directory.
>>>>>>
>>>>>> i'm not very happy with the naming of the schemes maybe someone 
>>>>>> has a better idea.
>>>>>>
>>>>>> here again the two examples for the  schemes:
>>>>>> resourcehtdocs:/bar/foo.xml
>>>>>> resourceyanelhtdocs:/bar/foo.xml
>>>>>
>>>>> I think that instead of resourceyanelhtdocs scheme we should put 
>>>>> yanel-htdocs inside htdocs of a resource type and use the single 
>>>>> scheme called 'htdocs':
>>>>> htdocs:/bar/foo.xml
>>>>> htdocs:/yanel/bar/foo.xml
>>>>>
>>>>> We talked with Simon about that, looks like there could be some 
>>>>> backwards compatibility issues, but it's much nicer isn't it?
>>>>
>>>> I like this better, too.
>>> maybe it's better but for backwards compatibility we would need add 
>>> another test if the file is in the old location or in the new.
>>> but it could make sense to use just one sorceResolver for both. it 
>>> would just access the root of the package.
>>> this would look like this.
>>>
>>> htdocs:/yanel-htdocs/bar/foo.xml -> 
>>> YOUR_RESOURCE_TYPE/yanel-htdocs/bar/foo.xml
>>> htdocs:/htdocs/bar/foo.xml -> YOUR_RESOURCE_TYPE/htdocs/bar/foo.xml
>>>
>>> this way it would be possible to access what ever is in the package. 
>>> not only htdocs/ yanel-htdocs.
>>>
>>> WDOT?
>>>
>> Hm, can a resource type access static resources that are situated in 
>> another resource type? or htdocs:/ is only for using locally in the 
>> resource type?
> yes you can access every resource-type by over giving the reource-type 
> you want to access to the SourceResolver.
>>
>> If it is cross-accessible (how?) then I guess allowing to get into any 
>> folder is a security whole... Meaning that a resource type *.jar is a 
>> self contained package which can have passwords and sensible stuff 
>> inside.
> you're right.
>>
>>> there is still the question of the naming. htdocs is not specific 
>>> enough, resourcehtdocs is long and doesn't really make sense IMO. in 
>>> java terminology what you get is named a resource (e.g. 
>>> getResourceAsStream()) so it unfortunately  this  would mean 
>>> resource-types resource which is confusing.
>>>
>>> some ideas:
>>> rtresource:/
>>> rtfile:/
>>> rtasset:/
>>
>> For me, as a non-linux user, even htdocs:/ is not informative enough:) 
>> I would go for something like asset:/ or htdocs:/
> don't really get you.
I mean I learned the word 'htdocs' only around one year ago when I 
needed to configure Apache. But even now I wouldn't be able to tell what 
every letter inside 'htdocs' mean:) So I say maybe asset:/ is a better 
name for that, otherwise htdocs:/ would be fine.

Evaldas

-- 
+41 79 616 53 76
www.linkedin.com/in/taroza

Optaros - www.optaros.com


More information about the Yanel-development mailing list