On 7/15/2010 1:48 AM, Max Carlson wrote:
On 7/14/10 3:30 PM, André Bargull wrote:
[...]
if ( this.locked == locked ) return;
+ this.locked = locked;
if ( locked ){
this.lock();
} else {
this.unlock();
}
lock() and unlock() set locked to "true" resp. "false", so the
additional line "this.locked = locked;" seems to be unnecessary.

The test is there because locked starts out set to 2, which is supposed
to signify that a) the layout is locked (it's truthy) and b) the layout
should be unlocked when its parent inits. This is to keep layouts from
updating until all the views they would be monitoring are created.

I didn't mean the if-test, but the additional assignment.
   if ( this.locked == locked ) return;
+  this.locked = locked; // not necessary here, lock() and unlock() set the 
property
   if ( locked ){
      this.lock(); // sets locked to true
   } else {
      this.unlock(); // sets locked to false
   }




+<!--- @access private
* Just used to effect a type cast of immediateparent to LzView
- */
- var vip:LzView = null;
+ -->
+ <attribute name="vip"/>
I'd just remove this attribute, there is no type cast anymore.

I put a comment in to put the type back later. I'm hoping we can add
more types and better support explicit typing with Tucker's new
attribute type work.

On 7/14/2010 6:21 AM, Max Carlson wrote:
Change 20100709-maxcarlson-v by maxcarl...@friendly on 2010-07-09
13:21:08 PDT
in /Users/maxcarlson/openlaszlo/trunk-clean
for http://svn.openlaszlo.org/openlaszlo/trunk

Summary: UPDATED: Move layout baseclass from the LFC to an LZX include

Bugs Fixed: LPP-9180 - Move non-essential parts of the LFC to LZX
includes (partial)

Technical Reviewer: ptw
QA Reviewer: hminsky

Details: Updated to address Tucker's comments:

Issues:

1) I don't like the idea of making this a component if it has to call
private API's (e.g., __LzApplyArgs). That seems like a bad road to
start down. I can't tell if it really needs to do that, or that's just
the way it was written. Is there a way to write this without using
private API's?

Fixed to use onconstruct handler instead.

2) I don't understand this comment in layout.lzx#94:

// ignore special default value of 2 until __parentInit();
especially given this change in construct:

// set as early as possible - can't wait for setter to be called
this.locked = args.locked;
Does every layout get a `locked` init arg?

I updated to address this. Now, construct() sets to 2, so any args can
override.

Questions:

1) Is it a bug that LPS components have to explicitly include other
components rather than rely on auto-includes?

I suppose relying on auto-includes would be convenient, but the
current way is much more explicit.

2) What's this about?

<script>
if ($as3) {
} else {
LzLayout = lz.layout; // publish for compatibility
}
</script>
I thought the old names would have been deprecated long enough now
that we would not need them?

Agreed. I removed that block.

Otherwise:

LaszloLayout,Library - Move to lps/components/utils/layouts/, rewrite
to use LZX syntax. Add child views in onconstruct handler instead of
overriding __LZapplyArgs().

lzx-autoincludes.properties - Add layout.lzx

utils/layouts/* - Explicitly include layout.lzx

Tests: Component sampler and debugger run as before.

Files:
D WEB-INF/lps/lfc/controllers/LaszloLayout.lzs
M WEB-INF/lps/lfc/controllers/Library.lzs
M WEB-INF/lps/misc/lzx-autoincludes.properties
M lps/components/utils/layouts/library.lzx
M lps/components/utils/layouts/wrappinglayout.lzx
M lps/components/utils/layouts/stableborderlayout.lzx
M lps/components/utils/layouts/constantlayout.lzx
M lps/components/utils/layouts/simplelayout.lzx
M lps/components/utils/layouts/reverselayout.lzx
A + lps/components/utils/layouts/layout.lzx
M lps/components/utils/layouts/resizelayout.lzx
M lps/components/utils/layouts/constantboundslayout.lzx
M lps/components/utils/layouts/simpleboundslayout.lzx

Changeset:
http://svn.openlaszlo.org/openlaszlo/patches/20100709-maxcarlson-v.tar



Reply via email to