Welcome, guest
(
Login
)
2007-04-10
Version 5, changed by jaredj 04/11/2007. Show version history
Meeting outcome:
Agenda Item 1:
Given, nothing else to report on.Agenda Item 2:
Tentative agreement of a rough path-accessor notation was reached. The agreement makes it so that the support can be added to most (if not all), store implementations through a simple Mixin function. The prototype function is provided below:getValueByPath = function(item, /*Array||String*/ path){
var pathArray;
if(dojo.isArray(path)){
pathArray = path;
}
if(dojo.isString(path)){
pathArray = path.split('/');
}
var value = item;
for(var i = 0; i < pathArray.length; ++i){
var nextItem = value;
var pathSegment = pathArray[i];
var value = this.getValue(nextItem, pathSegment);
}
return value;
}
The only requirement this makes on the store is that for non-simple attribute values, that they must also be stored as an 'item' in the store in some manner. Effectively this API allows you to drill down into references to other store items, allowing a complex item walk.
Agenda Item 3:
Micheal Smith (msmith) will be helping with porting the non-core stores to dojox. He will begin with the simplist of the non-core stores, CsvStore?. JaredJ? recommends the next store to tackle would be OpmlStore?. JaredJ? to work on providing/porting the XmlStore? to core.Agenda Item 1: Status:
- Dojo.data APIs and JsonItemStore are checked into the 0.9 split!
- 47 unit tests cover some of the helpers and the store.
- There are some test runner problems, but they appear to be either framework or xhrGet() problems. The issues are intermittant, and related to what tests are run before the JsonItemStore tests. Namely if the xhr tests are run before JsonItemStore, it causes failures in JsonItemStore. Very strange. Tracker is open on it: #2721
Agenda Item 2: Path Notation discussion continuation.
This is a holdover from last meeting. There was a lot of discussion on this topic but no real descision made. There were two main approaches outlined to consider and are listed below. These need to be further discussed and alternatives examined:JavaScript attribute accessor notation:Assume the following item structure:skinner: I'm hoping that once we settle on any specific approach, we'll then have answers to the list of 13 questions from our April 3rd meeting: 2007-04-03.var marge = {name:{first:"Marge", last:"Simpson"}};
var homer = store.newItem({name:{first:"Homer", last:"Simpson"}, spouse:marge});
var lisa = store.newItem({name:"Lisa", parents:{mom:marge, dad:homer}});
Then the following would be expected from accessor notation:var spouseFirstName = store.getValue(homer,"spouse.name.first");
// spouseFirstName should be: "Marge"var spouseLastName = store.getValue(homer,"spouse.name.last");
// spouseLastName should be: "Simpson"var spouse = store.getValue(homer,"spouse");Pros:
// spouseLastName should be: object [Object] (unless it implements toString() or the like)
- Simple to understand
- Assumes all items either return an atomic value, or the result of a toString() type conversion.
- skinner: i got lost there -- it looks like the above example of getValue(homer,"spouse") does not return an atomic value
Attribute aliasing:Cons:
- Unclear if you traverse items or not in this example.
- skinner: seems like that that style of access clearly would let you traverse item relationships, just by making a call like getValue(lisa,"parents.dad.name.first")
- Always returning a stringlike value as the result could get confusing/frustrating. What do you do if you *want* the object it returns instead of a string?
- How do you handle non-javascript based items, such as an XML Dom node?
var marge = {name:{first:"Marge", last:"Simpson"}};
var homer = store.newItem({name:{first:"Homer", last:"Simpson"}, spouse:marge});
var lisa = store.newItem({name:"Lisa", parents:{mom:marge, dad:homer}});
The store should set up a mapping of complex object structures to perhaps simpler attribute names. For example, spouse.name.first could be mapped to: spouseFirstName, and the lookup is:var spouseFirstName = store.getValue(homer,"spouseFirstName");
// spouseFirstName should be: "Marge"
Jaredj: I don't precisely see how this is any easier than the dot notation, other than it keeps you from seeing the actual item object structure.
skinner: I agree that the attributing aliasing approach doesn't make sense in the example above. I think attributing aliasing would only make sense in situations where a datastore is reading in "raw" XML or "raw" JSON, in some complex, verbose format, and then you want to be able to easily drill down into that and view it as just a collection of items. We would need to look at a few real-world data format examples to get a better feel for whether that makes sense.
Agenda Item 3: Discuss port/migration of non-core stores to Dojox.
The non-core stores all need to be ported to 0.9. These include CsvStore, RdfStore, YahooStore, Delicious, OpmlStore, etc. Need plan of attack and community help to get them all converted by M2 end.Minutes:
[INFO] Channel view for “#dojo-meeting” opened.-->| YOU (jared_j) have joined #dojo-meeting
=-= Topic for #dojo-meeting is “http://dojotoolkit.org/node/681”
=-= Topic for #dojo-meeting was set by wildbill on Monday, April 09, 2007 5:56:34 PM
*DojoMeetingBot* This channel is logged - http://www.dojotoolkit.org/logs/meetings
-->| ttrenka (n=ttrenka@c-24-131-182-228.hsd1.mn.comcast.net) has joined #dojo-meeting
<brian_skinner> The world will little note, nor long remember what we say here...
<brian_skinner> - Abraham Lincoln
<ttrenka> i seem to be having some connection issues with IRC so if I disappear, you know why
<jared_j> It seems to be everyone asks Jared day here at work. Sorry for being slow (and late)
<brian_skinner> likewise, my DSL connection in the new apartment is flakey, so i may get disconnected too
<brian_skinner> jared_j: no problem, i'm still waking up
<jared_j> I wish I was in bed. ;)
<ttrenka> what, did you move to china or something?
<brian_skinner> hi msmith -- good to see you
<msmith> hello.
<jared_j> msmith: If i remember right, you're the person who volunteered to help with porting the exisitng sample stores over to dojo.data 0.9 and updating them?
<brian_skinner> ttrenka: i'm still in the San Francisco Bay Area -- no excuse for the flakey DSL -- i need to call AT&T and see if they can fix it
<msmith> lucky that i just joined. I thought the meeting didn't start for another 3 hours.
<brian_skinner> :-)
<ttrenka> brian_skinner: ah. Was referring to the "just waking up"
<msmith> jared_j: yes, that's right.
<brian_skinner> ttrenka: i'm just a night owl
<ttrenka> gotcha
<brian_skinner> agenda: http://dojo.jot.com/2007-04-10
<jared_j> Since msmith is here, why don't we start with Agenda item 3 right after status?
<brian_skinner> sounds good
<jared_j> Anyway, status. We have the initial move of the base APIs and JsonItemStore into the 0.9 core. Buncha unit tests cover it and yesterday I enabled the xhr support so it should work as well as it did in 0.4.2 now. I think there's still some bugs in the new xhrGet code, though, as depending on the sequence of unit tests, xhr seems to flake out.
<jared_j> I have a tracker open for it and mailed Alex as well.
<ttrenka> alex is out of town for a few days so don't expect much comm from him
<brian_skinner> congrats on getting the code checked into 0.9, and thanks!
<jared_j> YW. Glad something is finally in. :)
<jared_j> So, things have been moving fairly well (not as fast as I'd like, but oh well).
<jared_j> So, this does lead well into agenda item 3. We have the other stores we need to do something with soonish. They're all doing into dojox.data as far as I understand it.
<brian_skinner> yup, putting them all in dojox.data sounds good
<msmith> previous plans (the current trac ticket) were to port all datastores to inherit from SimpleBaseStore, but now I understand that it's going to be a mixin class instead, right?
<jared_j> brian_skinner: You had a tracker open about refactoring the stores off RemoteStore and onto the simpleFetch mixin. msmith had some questions about that I couldn't answer. Can you explain your resoning behind moving mostof those off remotestore?
<jared_j> Not even a class, a mixin function
<jared_j> dojo.data.util.simpleFetch.js
<msmith> okay, i see.
<brian_skinner> yup -- i just sent mail about that question this morning -- let me copy and paste that here...
<jared_j> Theer was a lot of back and forth on it, but since it wasn't a complete store and such, and doing ti as a class bought you nothing over a mixin, it made since to make it as simple as possible.
<msmith> yes, that email had some good information in it.
<jared_j> I haven't seen that mail yet.
<brian_skinner> msmith asked: Why change the datastores to inherit from SimpleBaseStore instead of RemoteStore? Is there some advantage of this that I don't see?
<brian_skinner> and my answer was:
<brian_skinner> RemoteStore was designed to use for full read-write datastores, but most our datastores are just read-only stores, which makes inheriting from RemoteStore awkward.
<brian_skinner> Also, RemoteStore requires a specific in-memory data representation for its data items, which may not be appropriate for all datastores. In particular, the OpmlStore is intentionally using XML DOM nodes instead of JavaScript objects as its in-memory data representation, as a proof-of-concept for XML-based datastores, so that isn't possible using the RemoteStore data representation. And for...
<brian_skinner> ...the CsvStore, the RemoteStore data representation is overkill, since in CSV files all the attribute are single-valued, and none of the items have identities. The RemoteStore data structure requires all items to have identifiers, and stores all attribute values in arrays, all of which just adds complexity and overhead in the case of CsvStore.
<jared_j> Okay, fair enough and was what I was suspecting anyway. I just wanted the definitive from you on that. :)
<brian_skinner> ... i haven't thought as much about YahooStore and DeliciousStore -- I was mostly thinking about OpmlStore and CsvStore
<jared_j> the CsvStore would be the next simplest store, correct?
<brian_skinner> yup CsvStore is extremely simple
<jared_j> My opinion on porting them would be to go from simpliest -> most complex.
<brian_skinner> the actual parsing of the CSV file is the only complicated thing
<msmith> jared_j: i would agree with that approach.
<brian_skinner> jared_j: yup, simpliest -> most complex sounds good
<jared_j> So, if msmith wants to take a stab at porting that (and probably reusing some logic from JsonItemStore in the end), I would say give that one a shot. :)
<jared_j> This may be one of the first few things that shows up in dojox.
<msmith> okay. i can start with that. Porting means that a lot of the functionality of RemoteStore will have to be written for each datastore.
<msmith> of course, each datastore doesn't need to be as complex as RemoteStore.
<brian_skinner> i'm hoping that for a simple store like the CsvStore, you won't end up needing to re-create much of the RemoteStore stuff
<jared_j> Well, is CsvStore to be a read-only store, or read/write?
<brian_skinner> read only
<brian_skinner> or, if CsvStore does end up using a bunch of the same functionality as RemoteStore, then maybe it will make sense to introduce some common superclass
<jared_j> Then I would think a better starting base to look at is JsonItemStore and not much of what is impled today. Or am I wrong?
<brian_skinner> well, all the CSV file parsing code is still good, as is
<jared_j> And yes, if we canextrapolate out some functions, it's always good. Though the OO way has been frowned upon now and then. :(
<jared_j> Right, that can be repurposed.
<msmith> really? OO is frowned upon?
<ttrenka> it depends on what you mean by OO
<msmith> Object Oriented
<ttrenka> Java-style OO is somewhat frowned upon
<ttrenka> not entirely but somewhat.
<brian_skinner> well, maybe not "frowned upon" -- but viewed as just one of many tools in the tool belt, and not the end-all and be-all
<brian_skinner> not the right tool for every task
<ttrenka> supposedly that's changing but the details of how is beyond me
<ttrenka> lots of complaints of too many different styles of development throughout dojo, etc.
<msmith> okay, so that's why the API classes are not used as abstract classes at all.
<ttrenka> (just saying not advocating any one approach)
<ttrenka> msmith: with JS, the need for an abstract class as contract enforcement isn't the same as you'd need with Java or C#
<ttrenka> there's a very strong tradition of duck-typing with JS
<ttrenka> if that helps at all
<jared_j> msmith: Right. And here's why from a performance view. If all you ever do is replace all the functions, then you're wasting bandwidth to download something that just gets replaced.
<brian_skinner> actually, the dojo.data API classes are something of a nod towards the idea of Java interfaces
<msmith> ttrenka: yes, i understand that, and it makes sense.
<brian_skinner> msmith: thanks for volunteering to take this on -- feel free to ping me with questions as you go -- now that my big move is over i'll try to be more responsive than i've been
<jared_j> brian_skinner: Which Peller doesn't like and really wants to change, btw.
<ttrenka> he's not really the only one
<jared_j> msmith: Feel free to ping me too. I'll try to respond quickly.
<ttrenka> just so youknow
<brian_skinner> jared_j: yup, i can see peller's point on that -- ccmitchell and i once talked about trying to do some better idiom for supporting the notion of interfaces in dojo
<msmith> brian_skinner: i appreciate that. this is my first contribution to dojo, so i'm sure i'll have plenty of questions throughout.
<ttrenka> msmith: don't be afraid to ask anyone
<msmith> so, i can take the action item to begin porting CsvStore this week.
<jared_j> Sounds good.
<brian_skinner> so, agenda item two, or should we call it a day ;-)
<jared_j> As much as I'd like to call it a day, we should do 2. Is ccmitchel_ or others active? I would like to get other input than just our own. Last time it was just Ttrenka, skinner, and myself too.
<ttrenka> it would be useful
<brian_skinner> yup, more input would be good
<jared_j> Or do you have any input/insight on adgenda item 2, msmith? Doy you prefer one over the other, or have an aolternate opinion?
<brian_skinner> also, a few real-world use cases would help ground us
<jared_j> Yes.
<msmith> i can see the argument for both sides. while a syntax for "spouse.name.first" may not be universal for all datastore implementations, it certainly would be nicer than having to call getValue so many times.
<jared_j> The problem is if we put it on the interface, we need something all stores can conform to for it to be useful.
<ttrenka> msmtih: the issue is that it would need to be cross-store.
<jared_j> For it to bne some function that could be universailly exploited by widgets, for example.
<msmith> right. the syntax would have to be for a generic datastore. that requires each datastore to interpret that syntax into something meaningful for its own data implementation.
<jared_j> Correct.
<brian_skinner> we could have a simple mixin that was available across all datastores -- implemented by making calls to the standard getValue and getValues methods
<brian_skinner> could be done in about 5 lines of code
<jared_j> Doesn't that assume that each sub-item off an attribute is also an item?
<jared_j> For that to work.
<brian_skinner> yes, that's the only problem
<brian_skinner> works for traversal of item relationships, but not for nested attributed
<brian_skinner> attributes
<brian_skinner> sub-attributes
<msmith> ahh, interesting. so this case is where an attribute is actually an object structure.
<brian_skinner> yup
<jared_j> Yes.
<jared_j> Not a simple value.
<msmith> hmm... if i remember right, the datastore docs currently state that an attribute can be a simple value, an array of values, or an item reference. has that been extended to include objects as well?
<brian_skinner> msmith: that has not yet been extended to include objects as well, but that's part of what we're now thinking about doing
<brian_skinner> although, probably not arbitrary objects
<jared_j> Well, if that's enforced, then you right a simple mixin could generally handle it.
<jared_j> brian_skinner, ttrenka: Would it be a bad thing if we required that nested attribute accesses are only supported on things that are also references items in the store?
<ttrenka> sorry, phone. Gotta brb for a few minutes
<brian_skinner> jared_j: i'm not sure i understand -- are you saying we would support item traversal but not sub-attributes?
<jared_j> No, if the attribute in question was a reference to an item, then we could support the 'sub-attributes' through the getValue call as you noted.
<jared_j> But I'm really at a loss as to what to do here right now, sorry. I've been preoccupied with other unrelated issues.
<brian_skinner> sorry, i'm still not 100% sure that i'm following -- maybe you could give me an example?
<jared_j> You stated this could be implemented as a mixin, correct?
<jared_j> The only stipulation was the attribute would have to be an 'item'.
<brian_skinner> yup
<jared_j> Is that such a bad stipulation?
<brian_skinner> i can offer some example code for the mixin, if that would be useful
<jared_j> Is what I am wondering.
<brian_skinner> well, it still leaves us with the sub-attribute feature to sort out
<msmith> can sub-attributes be implemented as items?
<brian_skinner> msmith: we could do that, and it would simplify the implementation of all this -- but it might be conceptually weird
<brian_skinner> for example:
<jared_j> That's what I was wondering too.
<brian_skinner> var homer = store.newItem({name:{first:"Homer", last:"Simpson"}, spouse:marge});
<brian_skinner> it's weird to think of homer's "name" as being an independent item
<brian_skinner> for example, if you do
<brian_skinner> store.deleteItem(homer)
<brian_skinner> you'd like homer's name to get deleted too -- but if the name is a separate item, then it probably wouldn't get deleted
<msmith> well, then we're talking about whether or not the datastore supports cascade delete
<jared_j> Well, it depends on how you think of it, I guess. The item homer is a collection of items which represent someone.
<brian_skinner> jared_j: but then what if you do:
<brian_skinner> store.deleteItem(homer)
<jared_j> Do you depele all sub-items?
<jared_j> Er, delete
<jared_j> I guess it would depend on if the items are uniquely addressed or not.
<ttrenka> back
<brian_skinner> and 'name' gets deleted, but then 'marge' also gets deleted, which is bad
<ttrenka> sorry about that
<jared_j> I could see cases where ti would not be unqiue to one person.
<jared_j> marge, for example, or address.
<jared_j> It's entirely possible to have some things shared.
<brian_skinner> right, which fits with msmith's idea of cascading deletes -- we could cascade in the case of 'wholey-owned sub-items', but not related items
<jared_j> Right
<jared_j> It should only delete items which are completely unique to the containing item, I would think.
<brian_skinner> but if we require all datastores to support those semantics, how is that any simpler than just supporting sub-attributes :-)
<jared_j> But heck ... is Name even completely unique?
<jared_j> That's the question, isn't it?
<brian_skinner> when would {name:{first:"Homer", last:"Simpson"} not be unique?
<jared_j> Name: Bob Smith
<jared_j> Name John Johnson
<jared_j> Common names
<jared_j> Certainly may not be unique.
<msmith> coincidentally, Bob Smith is my dad's name. :)
<ttrenka> a better question is when would the object {name:...} be not unique, as in multiple references or not.
<brian_skinner> :-)
<brian_skinner> jared_j: but you still want each name item to be unique, even if the text string values aren't unique
<brian_skinner> for example, if i do
<brian_skinner> var name = store.getValue(homer, name);
<brian_skinner> store.setValue(name, 'first', 'SuperHomer')
<brian_skinner> you only want to impact the name of the single 'homer' item, not all items that have the name "Homer Simpson"
<jared_j> Fair Enough
<brian_skinner> if Bob Smith gets married and changes his name to Bob McDaniel, you don't want to change the names of all the Bobs
<jared_j> So, then we're back to where stores would have to selectively know what is always unqiue and what may not be.
<brian_skinner> yup
<brian_skinner> which may not be a bad feature to introduce -- it's just i was hoping to keep things simple
<jared_j> Well, again if we have some real-world examples that drove needing it. Right now we're theorizing.
<brian_skinner> should we put out a call for real-world examples, on the dojo-contributors list?
<ttrenka> unfortunately I've run across some, just nothing I can show you :(
<ttrenka> but there are times when you'll want the reference and other times you'll want the value.
<ttrenka> it was a Hibernate based system, object-oriented database setup
<brian_skinner> ttrenka: if you have time, could you 'mock up' a psuedo real world example, similar to what you've run into?
<msmith> brb
<jared_j> And as a side question to all this: Is it feasible to layer this in withotu changing the apis we have?
<ttrenka> brian: I think you already have but without a way of truly, uniquely identifying an object
<ttrenka> if you were to introduce a key to each object, that would make a difference
<ttrenka> name: { key:1, first:"Homer", last:"Simpson" }
<ttrenka> but that means dictating structure.
<ttrenka> ...at least, either dictating structure or applying our own on data load
<brian_skinner> ttrenka: we could introduce a key without dictating structure, if our Identity API allowed you to specify what attribute (or attributes) to use as the key field
<ttrenka> or to create a new one
<ttrenka> but yes.
<ttrenka> or we simply rely on the underlying structure to dictate by ref or by value
<ttrenka> i.e. two name objects with the same information is still 2 name objects
<ttrenka> but one name object referenced by two things is different
<ttrenka> ...still, it means traversing a data structure for cascade-type deletes
<ttrenka> what a pain. essentially we end up duplicating both a language and a garbage collector.
<brian_skinner> yup -- i don't think we should go there
<ttrenka> i think we should probably just keep it simple and not worry about things like cascading deletes
<ttrenka> in terms of JSON structures, we're never really going to do things by reference--and even if we did, letting scope rules operate is probably the right choice anyways
<ttrenka> with XML-based structures, unless your store is dealing with lots of xlink, we should also be ok with branch pruning, etc.
<ttrenka> I don't think the goal here should be to try to write an implementation of, say, SQL Server
<jared_j> Lord no.
<brian_skinner> ttrenka: i don't think we can make any assumptions about how the datastore is choosing to represent items in memory
<ttrenka> brian_skinner: I think we can make some very basic assumptions
<ttrenka> i think we have to
<ttrenka> but I think those assumptions need to be handled by the implementation of a particular store
<ttrenka> ...we should have a baseline which all things should meet, and give each store a little bit of headroom in terms of how
<brian_skinner> ttrenka: well, for example, sjmiles has talked about using JavaScript objects, but structuring the items data in arrays, rather than as JSON-style objects, for performance reasons
<ttrenka> ...I know that's what we've been working towards but we might want to be a little more liberal about it.
<ttrenka> brian: to be honest, I'm not sure where he's getting perf improvement ideas through that, but sure.
<ttrenka> at that point he's gaming the JS engine
<ttrenka> its reasonable to assume that hashing algorithm implementions will be more efficient than indexing ones
<ttrenka> (in terms of JS)
<ttrenka> either way we're a little off topic, my apologies
<brian_skinner> i haven't ever done any benchmarking -- i don't know what's faster or what uses less memory -- but i do think it's reasonable for datastore authors to want to try to do weird performance optimizations, based on their own local knowledge of the details of their data (for example, knowing that all items have the same attributes)
<ttrenka> ...i don't disagree. All I'm saying is that the rules with which an implementor does an implementation might be a little relaxed
<ttrenka> we shouldn't dictate cascading delete rules, for instance
<brian_skinner> yup
<ttrenka> if the store is doing object by reference, that should be a store-specific thing
<brian_skinner> we haven't yet introduced any cascading delete semantic
<ttrenka> right...sorry...was seeing us head there and was looking to head that off
<ttrenka> oh good christ
<ttrenka> sorry
<brian_skinner> so, going back to the idea of the simple mixin -- something that would work across all datastores, but would only work for traversing item relationships, not for creating a sub-attributes features -- here's the code i was thinking about:
<brian_skinner> store.getValueFromPath = function(item, /*String*/ path) {
<brian_skinner> var pathArray = path.split('/');
<brian_skinner> var value = item;
<brian_skinner> for (var i = 0; i < pathArray.length; ++i) {
<brian_skinner> var nextItem = value;
<brian_skinner> var pathSegment = pathArray[i];
<brian_skinner> var value = store.getValue(nextItem, pathSegment);
<ttrenka> was just checking the weather, apparently I'm gonna be getting something like 4 inches of snow over the next day
<brian_skinner> }
<brian_skinner> return value;
<brian_skinner> }
<brian_skinner> wow! where do you live?
<ttrenka> Saint Paul
<ttrenka> http://www.wunderground.com/cgi-bin/findweather/getForecast?query=55104
<brian_skinner> yikes, too cold
<ttrenka> its not as bad as you'd think.
<ttrenka> but this snow has to stop.
<ttrenka> so would that be something all stores would implement like that?
<ttrenka> I'm still thinking that we should probably force store implementors to create a basic path getter--*real* basic
<jared_j> He's suggesting it could be a mixin. Are you suggesting we leave it up to the store to imple the path traversal completely on their own?
<ttrenka> jared_j, yes I am
<ttrenka> "here's the spec, you meet it or the store isn't part of dojo.data"
<ttrenka> its harsh, but...
<jared_j> But it keeps us from having to worry about it.
<jared_j> Other than defining the spec
<ttrenka> right.
<ttrenka> right.
<ttrenka> ideally we'd grab something like JXPath and port it for usage
<brian_skinner> but then we've added another new feature that makes it one notch harder to write a conforming datastore, and we've made it one notch less likely that brad will update the offline toolkit to actually be a dojo.data datastore
<ttrenka> but I think that'd be a lot of code
<brian_skinner> why not just provide the 10-line mixin that automatically works for all datastores?
<ttrenka> i'm not convinced you'll get that working
<ttrenka> but it wouldn't be bad to make it available to ease the pain
<brian_skinner> what problem do you see with it?
<brian_skinner> shouldn't it just work?
<ttrenka> let me look again
<ttrenka> though I have to admit I don't like the idea of a separate method
<jared_j> You want it to just be part of getalue(), right?
<jared_j> Er, getValue.
<ttrenka> it'd be nice, yeah
<ttrenka> brian: that'd work, sure
<ttrenka> thought it was more recursive than it was
<jared_j> The only issue there is the API now shouldn't change unless absolutely necessary, according to Alex.
<ttrenka> (phone calls left and right, sorry)
<brian_skinner> having it as part of the standard getValue() will break our RdfStore
<jared_j> brian_skinner: I'm okay with the mixin. It's simple.
<ttrenka> brian: how badly, and how hard would it be to change?
<brian_skinner> ttrenka: if we try to do path-based access in the getValue() method itself, i don't see how to make that compatible with the RdfStore
<brian_skinner> in RDF, the attribute names are all URLs, with lots of / and . characters
<jared_j> Then the access by path would never work right? Regardless of being in getValue() or not
<brian_skinner> jared_j: yes, but at least the mere existence of the access-by-path feature wouldn't break the simple single-attribute access feature :-)
<brian_skinner> and it would be possible to make the access-by-path feature work, even for RDF, if we allowed it to take an array as the path arg
<jared_j> Or if we allow escapes
<jared_j> For whatever the path separator is decidedon
<jared_j> Escape all . with \. , for example
<jared_j> Path accessing in RDF would sure look ugly, but.
<msmith> back
<jared_j> I would prefer escapes over an array, in all honestly, but that's me.
<jared_j> Er, honesty
<brian_skinner> here's what the mixin code would look like if it allowed for either a string-path arg or an array-path arg:
<brian_skinner> store.getValueFromPath = function(item, /*Array||String*/ path) {
<brian_skinner> var pathArray;
<brian_skinner> if (dojo.isArray(path)) {
<brian_skinner> pathArray = path;
<brian_skinner> }
<brian_skinner> if (dojo.isString(path)) {
<brian_skinner> pathArray = path.split('/');
<brian_skinner> }
<brian_skinner> var value = item;
<brian_skinner> for (var i = 0; i < pathArray.length; ++i) {
<brian_skinner> var nextItem = value;
<brian_skinner> var pathSegment = pathArray[i];
<brian_skinner> var value = store.getValue(nextItem, pathSegment);
<brian_skinner> }
<brian_skinner> return value;
<brian_skinner> }
<brian_skinner> and then you could do either:
<jared_j> True.
<brian_skinner> var foo = store.getValueFromPath(item, 'foo/bar/baz');
<brian_skinner> or
<brian_skinner> var foo = store.getValueFromPath(item, [foo, bar, baz]);
<jared_j> To me, the array just doesn't imply the same sort of hierarchy, I have to admit.
<jared_j> Those don't look like they mean the same thing.
<brian_skinner> yup, but nobody would have to use the array syntax except the RDF people, or other people who have attribute identifiers with special characters
<brian_skinner> if we did the character escaping, what would the user's code look like?
<jared_j> Okay, assume attrs http://foo.bar, with sub attr http://bas
<brian_skinner> okay
<jared_j> If we path'ed on '.' (not /)
<ttrenka> still on the phone but what about quoted attributes?
<jared_j> var foo = store.getValueFromPath(item, "http://foo\\.bar.http://bas");
<jared_j> That looks pretty nasty too, admittedly.
<jared_j> Okay, so from a visual perspective, the array does end up cleaner
<brian_skinner> jared_j: that works for code where the attribute identifier is appearing as a literal -- but what about programmatic access?
<jared_j> And you don't have to string walk for escapes.
<jared_j> "Where they have what?
<jared_j> Programmatic access how? From a series of string vars?
<jared_j> If you're meaning from a series of vars that are strings, they'd have to do escape replacement on them before adding and passing them
<brian_skinner> Programmatic access like doing a binding to a table widget -- where you specify the columns of the table by getting passed an array of attributes (or attribute paths)
<jared_j> They'd have to be escaped by user code before being passed back in.
<jared_j> Ergo as odd as it looks to me, the array way is cleaner.
<brian_skinner> okay
<jared_j> So, forget my comment on escapes.
<jared_j> I revise my opinion. :)
<brian_skinner> ttrenka: what was your idea about quoted attributes?
<ttrenka> sorry, still on the phone, but something like:
<ttrenka> '"http://foo.bar/"."http://baz"'
<ttrenka> the same way that JSON attributes are quoted
<jared_j> Does that work?
<brian_skinner> yup, that seems like an improvement over other forms of escaping
<jared_j> Oh, dujh you're just quoting inside the string.
<jared_j> Yeah, that wouldwork too.
<jared_j> And is lots cleaner.
<ttrenka> the split will be a pita
<ttrenka> but yeah
<jared_j> Right.
<brian_skinner> it'll still require escaping for any data source that happens to use the " character as part of the attribute identifier
<jared_j> True.
<jared_j> So, from an easy of construction perspective, the array format wins for complex paths, I think.
<brian_skinner> ease of construction, and easy of parsing
<brian_skinner> ease
<jared_j> Right
<jared_j> Hah, you did it too. :)
<brian_skinner> :)
<brian_skinner> and the array thing can be optional
<jared_j> Should it be, though?
<jared_j> I would think they should always accept either
<jared_j> So users can just pick one and always work
<brian_skinner> yes -- the mixin should always accept either the path-string or array -- but the array syntax is optional for the user of the datastore -- they can use the path-string approach as long as their attribute identifiers don't have special characters
<jared_j> Right.
<jared_j> Sounds reasonable to me
<jared_j> So, we're hitting meeting end time. Do we have a reasonable option here?
<brian_skinner> and the array syntax has the nice side-effect that you can pass in attribute items as well as attribute name strings
<jared_j> Yup.
<brian_skinner> yup, time to go soon
<ttrenka> just remember we'll have the same issue with defining that from an attribute on a widget
<jared_j> I think getValueByPath() as a tentative fine?
<jared_j> Or just update getValue() to support it?
<jared_j> Well can't do the simple mixin if we updated getValue().
<jared_j> So, nevermind that.
<jared_j> Anyway, I'll write up the meeting conclusion tonight or tomorrow and people can review that and comment?
<brian_skinner> i'm okay with the getValueByPath() mixin as the tentative resolution
<brian_skinner> it seems mostly harmless
<jared_j> Ok.
<brian_skinner> and we can still add support for sub-attributes or other stuff later on, if we figure out what we want to do
<brian_skinner> sounds good -- thanks jared_j
<jared_j> Thanks. Good meeting everyone. Thanks for attending.
