Re: need otrunk.rest_enabled to be able to send back changes in an OTIncluded file.

[Aaron Unger]

I second the "don't use dynamic_otml when rendering the otml for
authoring purposes". The biggest problem I can think of is setting the
vendor interface appropriately for the author, in case they want to
use a probe to collect a dataset.

-- Aaron

On Apr 29, 2010, at 8:35 AM, Scott Cytacki wrote:

> Nope this hasn't ever worked. It has been a issue with authoring for
> a while that it only checks for changes and saves the first/main otml
> file.
>
> Can you disable the dynamic_otml when doing authoring like this? That
> seems like it would make the communication between investigations and
> otrunk the most simple.
>
> In English:
> OTrunk, here is a URL for you to edit, 'put' your changes back.
>
> as opposed to:
>
> OTrunk here is a URL for you to edit, don't send back changes to that
> file but instead send back changes to this referenced file.
>
> Scott
>
> On Thu, Apr 29, 2010 at 3:10 AM, Stephen Bannasch <sban...@concord.org
> > wrote:
>> I've fixed Investigations so editing a DataCollector in Java should
>> work (on
>> the test refactoring branch: emb-test) but then found a problem in
>> the Java
>> code.
>> When editing an embeddable in Java/OTrunk in Investigations (only
>> publicly
>> available for DataCollectors) the following properties are set in
>> the jnlp:
>>
>> <property name="otrunk.remote_save_data" value="true"/>
>> <property name="otrunk.rest_enabled" value="true"/>
>> <property name="otrunk.remote_url"
>> value="http://localhost:3000/embeddable/data_collectors/1292.otml"/>
>> This allows changes in the otml to be saved back to the
>> corresponding model
>> in Investigations.
>> However it appears this hasn't worked since implementing the
>> ability to
>> initially render dynamic_otml (to specify customizations per user
>> such as
>> vendor_interfaces). The dynamic otml uses OTInclude to load the
>> main otml
>> file.
>> It is this second otml file that needs to be persisted when the
>> user saves
>> their changes.
>> Is there currently a way to do this?
>> If not do you have a suggestion on how to fix this problem?
>>

--
You received this message because you are subscribed to the Google Groups "otrunk-dev" group.
To post to this group, send email to otrun...@googlegroups.com.
To unsubscribe from this group, send email to otrunk-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/otrunk-dev?hl=en.

[Stephen Bannasch]

Forwarded conversation
Subject: need otrunk.rest_enabled to be able to send back changes in an OTIncluded file.
------------------------

From: Stephen Bannasch <sban...@concord.org>
Date: Thu, Apr 29, 2010 at 3:10 AM
To: Scott Cytacki <scyt...@concord.org>, Aaron Unger <aun...@concord.org>
Cc: Noah Paessel <npae...@concord.org>

I've fixed Investigations so editing a DataCollector in Java should work (on the test refactoring branch: emb-test) but then found a problem in the Java code.

When editing an embeddable in Java/OTrunk in Investigations (only publicly available for DataCollectors) the following properties are set in the jnlp:

    <property name="otrunk.remote_save_data" value="true"/>

    <property name="otrunk.rest_enabled" value="true"/>

    <property name="otrunk.remote_url" value="http://localhost:3000/embeddable/data_collectors/1292.otml"/>

This allows changes in the otml to be saved back to the corresponding model in Investigations.

However it appears this hasn't worked since implementing the ability to initially render dynamic_otml (to specify customizations per user such as vendor_interfaces). The dynamic otml uses OTInclude to load the main otml file.

It is this second otml file that needs to be persisted when the user saves their changes.

Is there currently a way to do this?

If not do you have a suggestion on how to fix this problem?

----------
From: Scott Cytacki <scyt...@concord.org>
Date: Thu, Apr 29, 2010 at 8:35 AM
To: sbannasch <sban...@concord.org>
Cc: Aaron Unger <aun...@concord.org>, Noah Paessel <npae...@concord.org>, otrunk-dev <otrun...@googlegroups.com>

Nope this hasn't ever worked.  It has been a issue with authoring for
a while that it only checks for changes and saves the first/main otml
file.

Can you disable the dynamic_otml when doing authoring like this?  That
seems like it would make the communication between investigations and
otrunk the most simple.

In English:
OTrunk, here is a URL for you to edit, 'put' your changes back.

as opposed to:

OTrunk here is a URL for you to edit, don't send back changes to that
file but instead send back changes to this referenced file.

Scott

----------
From: Aaron Unger <aun...@concord.org>
Date: Thu, Apr 29, 2010 at 8:39 AM
To: Scott Cytacki <scyt...@concord.org>
Cc: sbannasch <sban...@concord.org>, Noah Paessel <npae...@concord.org>, otrunk-dev <otrun...@googlegroups.com>

I second the "don't use dynamic_otml when rendering the otml for authoring purposes". The biggest problem I can think of is setting the vendor interface appropriately for the author, in case they want to use a probe to collect a dataset.

-- Aaron

[stephen]

I can pretty easily remove the dynamic_otml wrapping when editing in
Java/OTrunk.

Right now the main use is to be able to collect data from real probes
and save that back to an Investigations DataCollector object to be
used as some type of static graph with real data in an Activity.

Given the limited set of authors I can imagine limiting this action to
Vernier GoIO interfaces won't be a huge issue (but I can easily
imagine it could be a problem).

I think it's likely that new customizations will be added to the
dynamic_otml generation in the future. I would like more flexibility
about which, when, where, and how various otml documents are
persisted.

Is it possible to develop a pattern/implementation that associates
these functions with the otml document itself?

[Scott Cytacki]

How about adding various http headers to the document that indicates
the server supports "puts" back to that address?

Doing that would probably make it easy to modify the OTrunk "database"
code, so it would attempt to send changes back to any otml that was
delivered with this header.

If the header approach won't work we can probably add an attribute to
the <otrunk> element that the database code could use. But I like
that less because it means the contents of the url will change
depending on how it is used which seems less REST like.

Scott