jasig-ssp IRC Logs-2013-01-29

Owned by Apereo Infrastructure
Last updated: Jan 29, 2013Version comment
2 min read

[11:09:13 CST(-0600)] <TonyUnicon> Hey Dan are you at the keyboard?

[11:09:40 CST(-0600)] <dmccallum54> yes

[11:10:06 CST(-0600)] <TonyUnicon> I'm sort of struggling with something, I'm hoping you can help

[11:10:10 CST(-0600)] <dmccallum54> ok

[11:10:21 CST(-0600)] <TonyUnicon> I'm trying to represent a one to many relationship in the ExtJs model

[11:10:37 CST(-0600)] <TonyUnicon> using hasMany: ect..

[11:10:54 CST(-0600)] <TonyUnicon> it looks like that is not used anywhere else in the app

[11:11:11 CST(-0600)] <TonyUnicon> and its not clear to me where else we serialize a one-to-many relationship to JSON

[11:11:47 CST(-0600)] <dmccallum54> um. let me see if i can track down an example. dont have an env up at the moment. give me a few.

[11:11:54 CST(-0600)] <TonyUnicon> ok

[11:25:59 CST(-0600)] <dmccallum54> so

[11:26:16 CST(-0600)] <dmccallum54> i'm not finding first-class hasMany relationships in client-side extjs models

[11:26:36 CST(-0600)] <dmccallum54> looking at how this is handled when there's a server-side hasMany relationship tho...

[11:26:50 CST(-0600)] <dmccallum54> for example: Challenge -> ChallengeCategory

[11:27:19 CST(-0600)] <dmccallum54> it looks like the client side Challenge model doesn't know anything about ChallengeCategories (but the server-side model does)

[11:27:44 CST(-0600)] <dmccallum54> and what ends up happening is the UI pulls both model lists as completely independent models

[11:29:00 CST(-0600)] <dmccallum54> in this particular case the UI actually represents more of the reverse relationship (categories having challenges) but the main point is that it relies on an API call to describe the relationship

[11:29:44 CST(-0600)]

<dmccallum54> i.e. you expand a category and there's an API call to /reference/categeory/

Unknown macro: {category-id}

/challenge, which returns a list of challenge models

[11:35:58 CST(-0600)] <TonyUnicon> ok, yeah that was the worst case scenario another API call

[11:36:03 CST(-0600)] <TonyUnicon> seems overkill

[11:36:16 CST(-0600)] <TonyUnicon> thanks for your help

[11:48:19 CST(-0600)] <dmccallum54> there's something to be said for consistency, but if you can accomplish the same thing more efficiently with a hasMany and without huge ripple effects, i've got no objections

[11:49:00 CST(-0600)] <TonyUnicon> judging by the number of forum posts on the Sencha site

[11:49:09 CST(-0600)] <TonyUnicon> it appears a lot of folks have trouble using it

[11:49:19 CST(-0600)] <dmccallum54> …again, worst case for us is to accidentally end up spending a lot of time on reengineering projects if we have a workable solution now, even if maybe non-ideal

[11:49:47 CST(-0600)] <TonyUnicon> its possible thats why they decided to use the api per entity approach

[14:46:08 CST(-0600)] <TonyUnicon> I did forget to mention today during the standup that I was able to rework the layout of the admin screens so that the TreeMenu is now collapsable

[14:46:18 CST(-0600)] <TonyUnicon> so there will be more real estate for the various forms and such

[14:46:23 CST(-0600)] <dmccallum54> cool

[14:46:34 CST(-0600)] <TonyUnicon> had to use a different layout manager but it looks pretty much the same