[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