On Fri, Aug 16, 2013 at 6:18 PM, Chris Geer <[email protected]> wrote:
> On Fri, Aug 16, 2013 at 2:53 PM, Erin Noe-Payne <[email protected] > >wrote: > > > On Fri, Aug 16, 2013 at 5:28 PM, Chris Geer <[email protected]> > wrote: > > > On Fri, Aug 16, 2013 at 2:13 PM, Erin Noe-Payne < > > [email protected]>wrote: > > > > > >> On Fri, Aug 16, 2013 at 4:00 PM, Chris Geer <[email protected]> > > wrote: > > >> > On Fri, Aug 16, 2013 at 12:56 PM, Matt Franklin < > > >> [email protected]>wrote: > > >> > > > >> >> On Fri, Aug 16, 2013 at 3:33 PM, Erin Noe-Payne < > > >> [email protected] > > >> >> >wrote: > > >> >> > > >> >> > On Fri, Aug 16, 2013 at 3:18 PM, Matt Franklin < > > >> [email protected] > > >> >> > > > >> >> > wrote: > > >> >> > > On Fri, Aug 16, 2013 at 3:15 PM, Gornstein, Daniel S. > > >> >> > > <[email protected]>wrote: > > >> >> > > > > >> >> > >> Matt, > > >> >> > >> > > >> >> > >> What is the upside of merging the branch into trunk before it > is > > >> done > > >> >> or > > >> >> > >> more complete? > > >> >> > >> > > >> >> > >> > > >> >> > > IMO, working off of trunk makes it more "real" for everyone. I > > >> think > > >> >> it > > >> >> > > should only be done if we are within 1-2 months of it being > > >> releasable. > > >> >> > > > > >> >> > > > >> >> > That feels like an ambitious schedule to me. I see 1 month as no > > >> >> > chance, and 2 months as very tight at best. > > >> >> > - There is a lot of outstanding api work to fill in missing or > > >> >> > incomplete endpoints > > >> >> > - We need to make changes to some models so that transitions > (f.e. > > >> >> > moving widgets between regions and pages) become state-based > > >> >> > > > >> >> > > >> >> Can you what you mean by this a little more? > > >> > > >> Say I want to move a regionWidget from one page to another. A > > >> regionWidget does not have a pageId property, so I can not make a > > >> change to its state and save to a restful endpoint. Similar problem > > >> for re-ordering portal pages. So we need to either update the models > > >> to have these references and then ensure that the controller / service > > >> layer detects the state changes and propagates accordingly, OR we need > > >> to implement special "action" rest endpoints on these models like > > >> /regionWidgets/1/move. I prefer the former but either will work. > > >> > > > > > > Wouldn't you update the page and add the regionWidget to a region on a > > > page, and remove it from another one? > > > > > > > I guess that's true. I'm guess I was just thinking there should be one > > atomic operation. > > > > Well, maybe. It depends on the data structure. Like I've stated before, I > don't really think a RegionWidget is a stand along object therefore they > can only exist in the context of a Page/Region. So you aren't really > changing an attribute of a regionwidget to move it, you are really deleting > a widget from one region and creating a widget in another region. > Conceptually, I agree; but, then we burden the API user with ensuring the widget's saved preferences and other properties remain intact. An atomic operation ensures it is just a move. > > > > > >> > > >> >> > > >> >> > > >> >> > - We need to harden the service layer to protect against data > > >> corruption > > >> >> > > > >> >> > > >> >> Yes, but we currently have this in trunk... > > >> >> > > >> > > >> I don't think we do? I sent an email to the dev list a few days ago > > >> about how the page service will let you set a null layout code. I > > >> think there are more examples if you start to dig, but that is all in > > >> trunk. > > >> > > >> >> > > >> >> > - We need to re-implement all of the front end as angular apps > > >> >> > > >> >> > > >> >> What is the state of this re-implementation? > > >> >> > > >> > > >> The portal is roughly 1 week in progress. Profile, widget store, admin > > >> panel, login, and anything else you can think of are not started. > > >> Progress will accelerate but each context will still have its share of > > >> custom work. > > >> > > >> >> > > >> >> > - We need to solve some pretty major architecture questions > > like... > > >> >> > - The entire authentication / authorization model > > >> >> > > > >> >> > > >> >> Authentication I agree, while the current authorization model is > not > > >> >> optimal, it should still work, right? > > >> >> > > >> > > >> Yes but it should be better and I think we will start to feel the pain > > >> when we think hard about generic contexts instead of just the two > > >> cases we have in place currently, so it's on my mind. > > >> > > >> >> > > >> >> > - How we will now handle internationalization > > >> >> > > >> >> > > >> >> The client messages js endpoint should still work, right? > > >> >> > > >> > > >> Essentially, but it will need to be expanded because much of the > > >> messaging that used to be in jsp's and was never added to client > > >> messages will now happen in angular. Having said that, require and > > >> angular both have built in internationalization support, so it may > > >> make more sense to go with the grain and use one of those than roll > > >> our own. > > >> > > >> >> > > >> >> > - How are we going to handle client-side view composition to > > keep > > >> >> > it from being to chatty > > >> >> > > > >> >> > > >> >> +1 > > >> > > >> I have a concept here for an angular service that works in the spirit > > >> of requirejs, in which any directive, service, etc can declare its > > >> 'view dependencies', which can then be requested en mass via a server > > >> side endpoint and cached. But that's conceptual only at this point. > > >> > > >> >> > > >> >> Fair enough. I haven't seen much discussion of state of the branch > > >> except > > >> >> for Jira tickets, so this helps. IMO, some of these things feel a > > lot > > >> like > > >> >> they need to be solved by V1, but not necessarily before branch > > merge. > > >> >> > > >> > > >> Of course; the merge can happen once 0.23 is released. This list is > > >> with respect to 1-2 months until angular is releasable. > > >> > > >> > > > >> > Matt brings up a good point here. I know there is a lot of work > going > > on > > >> > but I'm assuming that since the JIRA tickets are pretty lean (not > much > > >> > detail) you are using other methods to coordinate work between > > people. Is > > >> > there other communications that can be moved to the list so we can > all > > >> stay > > >> > abreast of what's going on? > > >> > > > >> > > >> Work on the angular branch started in earnest on monday - previous > > >> that the focus has been entirely on trunk and apis. This list of > > >> issues has not really been discussed beyond what has shown up on the > > >> list - it's mostly just a brain dump of what I have been thinking > > >> about. > > >> > > >> There has been some discussion off the list about the tasking for the > > >> angular tickets - I will be more transparent in tasking and discussion > > >> going forward. > > >> > > >> >> > > >> >> > > >> >> > > > >> >> > > > > >> >> > > > > >> >> > >> This causes people to not be able to use snapshot, and not > > release > > >> any > > >> >> > bug > > >> >> > >> fixes into trunk if you find something which needs attention > > right > > >> >> away. > > >> >> > >> > > >> >> > > > > >> >> > > Good point, but if we absolutely have to, we can release bugs > out > > >> of a > > >> >> > > branch that we create from 0.23 tag. > > >> >> > > > > >> >> > > > > >> >> > >> > > >> >> > >> Thanks, > > >> >> > >> Daniel Gornstein > > >> >> > >> > > >> >> > >> -----Original Message----- > > >> >> > >> From: Matt Franklin [mailto:[email protected]] > > >> >> > >> Sent: Friday, August 16, 2013 3:09 PM > > >> >> > >> To: [email protected] > > >> >> > >> Subject: 0.23 Release & Angular Merge > > >> >> > >> > > >> >> > >> We are coming up on the end of the month and IMO, it would be > a > > >> good > > >> >> > idea > > >> >> > >> to do a Rave release for 0.23 that includes the requirejs and > > >> Shindig > > >> >> > 2.5 > > >> >> > >> final changes. > > >> >> > >> > > >> >> > >> To support this, I have been committing minor bug fixes as I > > find > > >> >> them, > > >> >> > but > > >> >> > >> it would be good to get everyone who is able checking the > > current > > >> >> state > > >> >> > and > > >> >> > >> logging anything that needs to be fixed. > > >> >> > >> > > >> >> > >> I also see that Erin has been very active on the angular > branch. > > >> >> Given > > >> >> > >> that it is now the major thrust of the project, what would > > everyone > > >> >> > think > > >> >> > >> about merging that branch back to trunk after the 0.23 > release? > > We > > >> >> > would > > >> >> > >> then wait to do a 0.24 release until after the Angular code is > > >> ready. > > >> >> > >> > > >> >> > > > >> >> > > >> > > >
