Hi Kevin, Thx for checking on this before committing... and yes, I'm not that keen on this change. I'll try to respond more fully tomorrow, but if you can hold off for now, I'd appreciate it. Cheers Dan
Sorry to be brief, sent from my phone On Dec 4, 2011 8:02 PM, "Kevin Meyer - KMZ" <[email protected]> wrote: > Guys, > > In order to provide support for object / entity level support of hidden() > and disabled(), I have had to make changes to the metamodel and > related. > > Specifically, adding: > Consent isVisible(AuthenticationSession session); > and > Consent isUsable(AuthenticationSession session); > to > oai.core.metamodel.adapter.ObjectAdapter. > > Of course, this had some knock-on effects on derived classes (most > specifically, PojoAdapter and the metamodel wrapper. > The metamodel wrapper also had to be modified to actually check for > the new behaviour. > > Anyway - looking at how the HTML Viewer *still* needs to be changed > (the whole concept of making an entire entity read-only is new), I'm left > wondering if Dan's suggested kludge might be the better approach! > > The details: > I have provided support for checking if an object is read-only/visible. > Dan's suggestion was to implement this by manually forcing each > field/action to be read-only/visible. > > > > > My changes: > An object can specify if it is hidden or read-only with a single pair of > methods. > > Advantage: > Using my additions, viewers can check an object first, before checking > individual fields/properties. > > Disadvantage: > Viewers have to be modified(?). > > > > > Using Dan's suggestion (of forcing the behaviour onto each field): > Make each field/property check to the see if owning entity is read- > only/visible. > > Advantage: > Should work with existing viewers out of the box. > > Disadvantage: > Kludge. Seemed inefficient to me. The same "validate" method will be > called multiple times - 1 for each method/property in the entity. > > > > Opinions, please? > > > > >
