-
Notifications
You must be signed in to change notification settings - Fork 2
ImplementationDecisions
Not much thought to layouts or best user experience. Not a pretty application. The goal is to showcase some of what Enyo can do, but mostly provide a springboard for anyone looking for a turnkey web app. Future work may focus on incorporating style templates.
Had a lot of problems trying to inherit components, not sure it even works statically. So I had to resort to inheriting builder methods, and in those methods create and render components.
One of the most difficult things to do dynamically are the ListItems. Looking at .../source/views/auth/body/MessageCenterPage.js setupMessageThreadRow() method. I haven't been able to find an Enyo example that does it this way. Usually the row content as a static template like this:
{kind: "List", classes: "list-sample-contacts-list enyo-unselectable", fit: true, multiSelect: true, onSetupItem: "setupItem", components: [ {name: "divider", classes: "list-sample-contacts-divider"}, {name: "item", kind: "ContactItem", classes: "list-sample-contacts-item enyo-border-box", onRemove: "removeTap"} ] },
Or using the template attribute:
inEvent.template="<div style=\"border: 2px solid #000; font-size: 20px; padding: 10px;\">" + inEvent.context.fromUsername + "</div>";
And the problem is it assumes that every row in the list has the same layout. There are many work arounds to make rows appear differently from their peers, like having every row contain multiple icons and showing/hiding them as appropriate.
While the List with the ListItem template is powerful in Enyo. The limited ability to define row layouts on the fly seems like a real limitation.
One interesting thing with dynamic components is they need an explicit owner. If done statically the owner is what ever Kind that contains the components[] array.
Dynamically one would expect that the owner would be the component that creates the new object, but no dice. This is wrong:
someEnyoInstance.createComponent({kind: enyo.Control});
This is correct
someEnyoInstance.createComponent({kind: enyo.Control, owner: someEnyoInstance});
So the setupPageBody() takes an owner argument so the things can be bound to the View instead of the PageBody. You'll see some places using 'this', in which case things are bound to the PageBody. This is confusing, but allows events and callbacks to be defined in the PageBody kind. If all methods are moved up the the parent, then everything could be consistent. But I don't want the view cluttered, so more views in the inheritance tree? Probably the right thing to do, I need to revisit this.
You'll see methods called to explicitly bind data on input controls. The method in the .../source/views/ParentPage.bindInputData() basically does what the Enyo MVC framework using the bind array. You may ven find some useless references sprinkled throughout the code. I left some there to remind me that I should revisit this.
, bindings: [ { from: ".$.username.value" , to: "mvcApp.controllers.publicController.test" , kind: "enyo.InputBinding" } , { from: ".$.password.value" , to: "mvcApp.data" , kind: "enyo.InputBinding" } ]
Unfortunately there are multiple flavors of coding conventions. You'll see some javaScript, java and C/C++ mixed.
I try to use single quote (') but old habits die hard and you'll see double quotes (") sprinkled throughout.
You'll see this used
attribute1 : 'value 1' , attribute2 : 'value 2' , attribute3 : 'value 3' Which I saw in one of the JS projects I was researching during this project. It's a bit of a pain lining things up (depending on your editor). But I like being able to glance at a block of code and know immediately that it's an attribute list instead of logic.
This is common in JavaScript to improve speed. Not too necessary if you're minifying code.
if(isTrue)dosomething(); if(isAlsoTrue){dosomehtingelse();}else{someError();}
I prefer my code to readable, always thinking about someone new to the project and/or language.
if (isTrue) { dosomething(); } if (isAlsoTrue) { dosomehtingelse(); } else { someError(); }
And a Java code convention that is a pet peeve of mine. This seems to pretty common
} else {
Which makes no sense since most of the conventions are about reducing line count. But that isn't the only reason I prefer
} else {
When scanning lines of code, the logical block doesn't end with the "}" but continues with the "else", so why put it on a new line? Whiny, whiny, whiny, I know. But when it comes down to it, all code conventions are arbitrary, the important thing is to be consistent.
Add a Contact Page for Authorized users
Directories and Package Layout
Why is the project structured this way?