Merge lp:~rharding/launchpad/productjs into lp:launchpad
| Status: | Merged |
|---|---|
| Approved by: | Richard Harding on 2012-09-12 |
| Approved revision: | no longer in the source branch. |
| Merged at revision: | 15975 |
| Proposed branch: | lp:~rharding/launchpad/productjs |
| Merge into: | lp:launchpad |
| Prerequisite: | lp:~rharding/launchpad/pp_register |
| Diff against target: |
786 lines (+515/-235) 5 files modified
lib/lp/app/javascript/testing/testrunner.js (+3/-1) lib/lp/registry/javascript/product_views.js (+369/-0) lib/lp/registry/javascript/tests/test_product_views.html (+58/-0) lib/lp/registry/javascript/tests/test_product_views.js (+74/-0) lib/lp/registry/templates/product-new.pt (+11/-234) |
| To merge this branch: | bzr merge lp:~rharding/launchpad/productjs |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| j.c.sackett (community) | 2012-09-11 | Approve on 2012-09-11 | |
|
Review via email:
|
|||
Commit Message
Pull product-new.pt JS into a new module and being some tests around it.
Description of the Change
TBD
| Richard Harding (rharding) wrote : | # |
#39: You are correct. The next step is to add in code to try to figure out how to work around adding information type as a feature flag so this isn't currently processed.
#66 This was from the existing code. I just kept the regex into place. I'm not 100% sure on the best way, but that would be a follow up UX fix for submitting a project that might require some discussion/testing.
#266 I've attempted to keep with the Y.View api in YUI 3.5.1 as at some point this might be a View object vs just JS that runs on the page.
It doesn't involve renderUI and bindUI because those are specific to the Widget interface and this isn't a Widget. A Widget is a much smaller more reusable bit of JS/HTML combo while this is more a large View with events and code that occurs within it.
#291 Yea, I guess that not all node selections are done via ATTRS. I only pulled in the ones that were used in more than one place and noted that they're made ATTRS so that we don't redo the DOM lookup when it's not required. This is because I'm working on breaking apart the old code that one as one giant JS block into a series of calls I can work on splitting and testing as they break apart.
| j.c.sackett (jcsackett) wrote : | # |
> #39: You are correct. The next step is to add in code to try to figure out how
> to work around adding information type as a feature flag so this isn't
> currently processed.
Thank you.
> #66 This was from the existing code. I just kept the regex into place. I'm not
> 100% sure on the best way, but that would be a follow up UX fix for submitting
> a project that might require some discussion/testing.
Ah, yes, I missed that.
> #266 I've attempted to keep with the Y.View api in YUI 3.5.1 as at some point
> this might be a View object vs just JS that runs on the page.
>
> It doesn't involve renderUI and bindUI because those are specific to the
> Widget interface and this isn't a Widget. A Widget is a much smaller more
> reusable bit of JS/HTML combo while this is more a large View with events and
> code that occurs within it.
Ah, okay. I saw `render` and `bindUI` and thought `Widget`.
> #291 Yea, I guess that not all node selections are done via ATTRS. I only
> pulled in the ones that were used in more than one place and noted that
> they're made ATTRS so that we don't redo the DOM lookup when it's not
> required. This is because I'm working on breaking apart the old code that one
> as one giant JS block into a series of calls I can work on splitting and
> testing as they break apart.
Ok, thanks.
| Richard Harding (rharding) wrote : | # |
I couldn't land this due to a timeout error when running the test suite on ec2. Deryck found that flattening the namespace allowed the tests to pass.
In order to keep some structure, but with a smaller namespace, I've tried to setup a standard that drops the lp. since that's just something all our code has. It does mean we have to watch for collisions with the raw YUI library, but that's well documented.
What I am going for is a nesting based on the 'type' of code in question. In this case, I'm writing up code for an html view. This might have also been a model, utils, etc.
I also didn't nest within the registry namespace by doing registry.product. Instead, the name of the module is registry_product. In this way, there can be many modules that add code to the views.registry namespace. This module adds a class NewProduct. So the full name is Y.views.
If there was a model that went with this to be used, it would be in Y.models.
| Deryck Hodge (deryck) wrote : | # |
I appreciate you making these changes, Rick, and I like the general approach you're taking. I agree that we drop the "lp" namespace. I'll follow up about this to the dev list. I. however, don't care for the "views" namespace. It's a bit generic, and could lead to conflict later, should the YUI team ever chose to use that for something related to their view code. I would vote for a couple of variations of the following...
Either using the app name for the first name space followed by the class; something like Y.registry.

#39: should be _information_type, not _inforation_type
#66: Is it necessary to prevent invalid characters from being typed? That seems like bad UI to me--if I (not knowing good urls) put in bad characters, but nothing happens, I feel like the app or my keyboard is broken. Better maybe to have a dynamic warning that comes up saying it's invalid and what the invalid character is? Or throw away the dynamics and just up the warning after typing ends/submission occurs and validation fails?
#266: Why are we writing our own render method? This will break renderUI and syncUI calls down the road if anyone wants to add that, right? Wouldn't all of this render code be better set in renderUI and called by the render cycle?
#291: Given they all say the same thing (barring the one one line #330) I'm not sure these comments help much? They're not telling me anything that I can't see just from looking--I tend to err on no comment are better than unneeded ones. If you have these b/c of auto-docs of some sort, I would prefer "Lazy load the search results node" etc over "the found node" since if I'm scanning auto-docs I'm probably not pulling up the function.