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