[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [corona-dev] content-format belongs on resource not on repository-descriptor
|
I think I missundestood you when responding previously.
Is your suggestion that we only define content-type (eg. team member
repository) and access-type (eg. Jackrabbit repository)? Then you fetch
the resource, and ask what is its format?
If yes, I think it won't work. While it may work for Jackrabbit, where
you can put any meta-data in it, how would you do it with file
accessible through HTTP or even laying at disk?
Marcin
Everitt, Glenn napisał(a):
[Marcin}
Yes then we would have it much simplified. The repository adapters are
simply for "access-type". Viewers would be in general for
"content-format". The "content-type" would then be for finding
repositories with some higher level content.
[Glenn]
As I mentioned in my earlier post I cheated and used the repository name
to specify the higher level content. I don’t think this approach will
work in general. The problem is since the name is for a repository you
can only specify one “higher level content” per repository. You can cheat
to get around this by specifying more than one repository-descriptor for
the “same” repository for maybe a database table with team members and
managers. You would have to create 2 repository-descriptors one for
“TeamMembers” and one for “Managers”. So, that is why we need
content-format to be on the specific resource
[Marcin]
But then we would need to have some kind of "content parsers". Use case
again with team repository. The XML file is kept in Jackrabbit. The
repository adapter returns content of the file. The overview page wants
to know how many team members there are. So we provide some "content
parser" (or reader) which returns all members in the team. It does it by
reading file from repository adapter, parses it and return user records.
But then I think the repository adapter should have a method like
getResouceStream(). Again the XML team member. It might be kept in:
file, WebDAV, JackRabbit, CVS or BLOB DB field. The input stream would
make it parsable no matter where would be stored. What would now return
the "fetchResource()" methods in repository adapter for all those
access-types?
[Glenn]
What you are proposing with the getResourceStream is very similar to
what Jackrabbit JCR implements
on a Node Property. We could change IReposity fetchResource to return
a ResourceObject instead of Object with methods
getResouceStream
getMetaData
getDataType
getResourceId
So how much work to change it?
Glenn
The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the
named addressee or an authorized designee, you may not copy or use it,
or disclose it to anyone else. If you received it in error please
notify us immediately and then destroy it.
------------------------------------------------------------------------
_______________________________________________
corona-dev mailing list
corona-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/corona-dev
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.