Hey Alexandre,
I'm sorry but I don't really understand what you mean.
If you mean that I can implement a VFS in my own App then sure I could do this but as I
said that would introduce the problem of keeping the configuration of both VFS in sync.
Not insurmountable, but I still think that it would be in the interest of the wb-app and
uberfire in general to expose the VFS via CRUD Rest (or whatever). I would make it simple
to write a custom interface (be it a native mobile app or whatever else) for the wb
without having to write uberfire components (which at this point in time is due to the
lack of documentation - imho - a barrier to adoption).
However, if you mean that there is a VFS API by the wb or uberfire that I could easily
expose to my app that would be exactly what I was looking for. I have been digging through
the source code but as an outsider and newcomer in terms of uberfire, droolsjbpm I
couldn't find a way to do this. A pointer to the right files and few words would be
greatly appreciated :)
Cheers, Alex
Am 13.08.2013 um 13:52 schrieb Alexandre Porcelli <porcelli(a)redhat.com>:
If you really need a programatic CRUD with a GIT access abstracted,
you can use the VFS API.
On Aug 13, 2013, at 8:40 AM, Alexander Herwix <alex(a)herwix.com> wrote:
> Hey Mark,
>
> first of all thanks for the information but I disagree. I would see providing a CRUD
api as a helpful feature as this would provide a single place for asset management. Having
access via GIT is fine, but then I have to sync the repo location (changes, renames,
deletes) and the GIT VFS implementation is touted to be pluggable, so asset management
with a custom VFS provider could become a real pain. This might be an edge use case as not
everyone needs to provide a custom-ui and run the wb at the same time, however, I still
think it's a valid one, especially if you think about native mobile apps.
>
> Anyway, keep up the good work.
>
> Cheers, Alex
>
>
>
> Am 12.08.2013 um 19:42 schrieb Mark Proctor <mproctor(a)codehaus.org>:
>
>>
>> On 12 Aug 2013, at 18:28, Alexander Herwix <alex(a)herwix.com> wrote:
>>
>>> Hey guys,
>>>
>>> I really love the new wb-apps, but documentation is really pretty sparse
right now, so maybe you guys can help me out :)
>>>
>>> Is there any documentation on the authoring REST-Api? I have already asked on
the jbpm forum, where they said that there should be one but that it's not documented
yet. I have found some repository, group stuff exposed (drools-wb-rest), process-execution
(jbpm) but no real asset authoring.
>>
>>>
>>> The reason I need this access, is to use the kie-wb in parallel to my own gui
with the kie-wb as admin interface. I know there have been improvements with
user-extendable editors via uberfire and GWT but with the level of documentation as it is
right now, I can't make that dive now. But with my data already in the wb it should be
trivial to port my user-facing gui in the future if the need should arise.
>> We will not being doing any rest CRUD apis; although there are other rest
api's for administration stuff. As this is just git a variety of git apis exist for
every platform already. We have however done a java nio2 back port (api copy, with
namespace change), vfs that works with GIT remotely. But it is obviously java only.
>>
>> This should probably suffice any needs you have, for accessing and integrating
with content.
>>>
>>> What do you guys think? Is this possible with the upcoming droolsjbpm 6
release? Could anyone provide at least rudimentary documentation of (all) the REST APIs?
It would really help if there would be at least a unified feature list of what to expect
in open APIs of the kie-wb (so for jbpm as well as drools).
>> We don't ned to provide docs for how GIT works, but we will provide docs on
the rest apis we do support - just nothing yet. Still working over time on fixing critical
bugs.
>>>
>>> Thanks for any help on advance!
>>>
>>> Cheers, Alex
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/rules-users
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users