Error on submitting custom <ft:object>: object saved correctly, but not refobjects table

[Tomek Kott]

Hi All,

I have a type (gsgEFR) which has a webskin (editStatus). Now this webskin is a bit of a catch all, because there is a related type (gsgEFRMessages) that it also edits. The problem I am having is this:

when the webskin submits an <ft:form> with an <ft:processformobjects typename="gsgEFRMessages"> the actual item gets saved properly as a gsgEFRMessages type. however, the refobjects table is updates at gsgEFR. hence, when trying to view the newly created object via the objectid, I get nonesense.

Is this a bug or is this expected behavior for the refobjects table considering the underlying webskin is of type gsgEFR?

Thanks!

Tomek

--~--~---------~--~----~------------~-------~--~----~
You received this message cos you are subscribed to "farcry-dev" Google group.
To post, email: farcry-dev@...
To unsubscribe, email: farcry-dev+unsubscribe@...
For more options: http://groups.google.com/group/farcry-dev
--------------------------------
Follow us on Twitter: http://twitter.com/farcry
-~----------~----~----~----~------~----~------~--~---

[Tomek Kott]

Ok... I tracked this sucker down (only took half the day).

Type setup:gsgEFRMessages has a property: efrID, uuid, which had a custom ftlibraryData method with libraryDataTypename="gsgEFR" (instead of calling it on gsgEFRMessages). This was a whole separate problem which I submitted here; http://bugs.farcrycms.org/browse/FC-1982.

Anyway, the uuid property creates a component object gsgEFR and then calls "getData" (which is a fourq function) on the objectid of the type being edited. Since this is the first time that the objectid is called (for a new gsgEFRMessage), this function calls "getDefaultObject" which calls "createRefObject" which puts into the refobjects table the values of the objectid and gsgEFR.

The problem here is that the objectid is actually a gsgEFRMessages type, and the only reason gsgEFR is called is because it made more sense to put the library function with that component rather than with gsgEFFRMessages. Since the refobjects table is not checked or overwritten on a save, the result is that the refobjects table points to a gsgEFR type. When just calling the page using the objectid (which again, is really a gsgEFRMessage type), it uses gsgEFR displayBody, which is incorrect.

So there is a problem in this process --- either the uuid tool shouldn't be calling getData (which would make sense, as the libraryData is a method call, not an object call), or each save of an object should check the refobjects table to make sure that the objectid points to the proper type.

Daemonites please let me know if you want this posted as a bug and which of the suggested solutions to mention in that bug.

Thanks,

Tomek

On Wed, Sep 23, 2009 at 11:31 AM, Tomek Kott <tkott.spam@...> wrote:

Hi All,

I have a type (gsgEFR) which has a webskin (editStatus). Now this webskin is a bit of a catch all, because there is a related type (gsgEFRMessages) that it also edits. The problem I am having is this:

when the webskin submits an <ft:form> with an <ft:processformobjects typename="gsgEFRMessages"> the actual item gets saved properly as a gsgEFRMessages type. however, the refobjects table is updates at gsgEFR. hence, when trying to view the newly created object via the objectid, I get nonesense.

Is this a bug or is this expected behavior for the refobjects table considering the underlying webskin is of type gsgEFR?

Thanks!

Tomek

--~--~---------~--~----~------------~-------~--~----~
You received this message cos you are subscribed to "farcry-dev" Google group.
To post, email: farcry-dev@...
To unsubscribe, email: farcry-dev+unsubscribe@...
For more options: http://groups.google.com/group/farcry-dev
--------------------------------
Follow us on Twitter: http://twitter.com/farcry
-~----------~----~----~----~------~----~------~--~---

[Blair McKenzie-2]

Put everything in. Matt will probably need to look at it, and he's not available to decide atm.

Blair

On Thu, Sep 24, 2009 at 6:02 AM, Tomek Kott <tkott.spam@...> wrote:

Ok... I tracked this sucker down (only took half the day).

Type setup:gsgEFRMessages has a property: efrID, uuid, which had a custom ftlibraryData method with libraryDataTypename="gsgEFR" (instead of calling it on gsgEFRMessages). This was a whole separate problem which I submitted here; http://bugs.farcrycms.org/browse/FC-1982.

Anyway, the uuid property creates a component object gsgEFR and then calls "getData" (which is a fourq function) on the objectid of the type being edited. Since this is the first time that the objectid is called (for a new gsgEFRMessage), this function calls "getDefaultObject" which calls "createRefObject" which puts into the refobjects table the values of the objectid and gsgEFR.

The problem here is that the objectid is actually a gsgEFRMessages type, and the only reason gsgEFR is called is because it made more sense to put the library function with that component rather than with gsgEFFRMessages. Since the refobjects table is not checked or overwritten on a save, the result is that the refobjects table points to a gsgEFR type. When just calling the page using the objectid (which again, is really a gsgEFRMessage type), it uses gsgEFR displayBody, which is incorrect.

So there is a problem in this process --- either the uuid tool shouldn't be calling getData (which would make sense, as the libraryData is a method call, not an object call), or each save of an object should check the refobjects table to make sure that the objectid points to the proper type.

Daemonites please let me know if you want this posted as a bug and which of the suggested solutions to mention in that bug.

Thanks,

Tomek

On Wed, Sep 23, 2009 at 11:31 AM, Tomek Kott <tkott.spam@...> wrote:

Hi All,

I have a type (gsgEFR) which has a webskin (editStatus). Now this webskin is a bit of a catch all, because there is a related type (gsgEFRMessages) that it also edits. The problem I am having is this:

when the webskin submits an <ft:form> with an <ft:processformobjects typename="gsgEFRMessages"> the actual item gets saved properly as a gsgEFRMessages type. however, the refobjects table is updates at gsgEFR. hence, when trying to view the newly created object via the objectid, I get nonesense.

Is this a bug or is this expected behavior for the refobjects table considering the underlying webskin is of type gsgEFR?

Thanks!

Tomek

--~--~---------~--~----~------------~-------~--~----~
You received this message cos you are subscribed to "farcry-dev" Google group.
To post, email: farcry-dev@...
To unsubscribe, email: farcry-dev+unsubscribe@...
For more options: http://groups.google.com/group/farcry-dev
--------------------------------
Follow us on Twitter: http://twitter.com/farcry
-~----------~----~----~----~------~----~------~--~---

[Tomek Kott]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Bug posted at:

http://bugs.farcrycms.org/browse/FC-2011

On Wed, Sep 23, 2009 at 7:55 PM, Blair McKenzie <shib71@...> wrote:

Put everything in. Matt will probably need to look at it, and he's not available to decide atm.

Blair

On Thu, Sep 24, 2009 at 6:02 AM, Tomek Kott <tkott.spam@...> wrote:

Ok... I tracked this sucker down (only took half the day).

Type setup:gsgEFRMessages has a property: efrID, uuid, which had a custom ftlibraryData method with libraryDataTypename="gsgEFR" (instead of calling it on gsgEFRMessages). This was a whole separate problem which I submitted here; http://bugs.farcrycms.org/browse/FC-1982.

Anyway, the uuid property creates a component object gsgEFR and then calls "getData" (which is a fourq function) on the objectid of the type being edited. Since this is the first time that the objectid is called (for a new gsgEFRMessage), this function calls "getDefaultObject" which calls "createRefObject" which puts into the refobjects table the values of the objectid and gsgEFR.

The problem here is that the objectid is actually a gsgEFRMessages type, and the only reason gsgEFR is called is because it made more sense to put the library function with that component rather than with gsgEFFRMessages. Since the refobjects table is not checked or overwritten on a save, the result is that the refobjects table points to a gsgEFR type. When just calling the page using the objectid (which again, is really a gsgEFRMessage type), it uses gsgEFR displayBody, which is incorrect.

So there is a problem in this process --- either the uuid tool shouldn't be calling getData (which would make sense, as the libraryData is a method call, not an object call), or each save of an object should check the refobjects table to make sure that the objectid points to the proper type.

Daemonites please let me know if you want this posted as a bug and which of the suggested solutions to mention in that bug.

Thanks,

Tomek

On Wed, Sep 23, 2009 at 11:31 AM, Tomek Kott <tkott.spam@...> wrote:

Hi All,

I have a type (gsgEFR) which has a webskin (editStatus). Now this webskin is a bit of a catch all, because there is a related type (gsgEFRMessages) that it also edits. The problem I am having is this:

when the webskin submits an <ft:form> with an <ft:processformobjects typename="gsgEFRMessages"> the actual item gets saved properly as a gsgEFRMessages type. however, the refobjects table is updates at gsgEFR. hence, when trying to view the newly created object via the objectid, I get nonesense.

Is this a bug or is this expected behavior for the refobjects table considering the underlying webskin is of type gsgEFR?

Thanks!

Tomek

--~--~---------~--~----~------------~-------~--~----~
You received this message cos you are subscribed to "farcry-dev" Google group.
To post, email: farcry-dev@...
To unsubscribe, email: farcry-dev+unsubscribe@...
For more options: http://groups.google.com/group/farcry-dev
--------------------------------
Follow us on Twitter: http://twitter.com/farcry
-~----------~----~----~----~------~----~------~--~---