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. > > >> > >> >> > >> >> > >> >> > - 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. > >> >> > >> > >> >> > > >> >> > >> >
