[Laszlo-dev] [Laszlo-checkins] r11229 - openlaszlo/trunk/demos/calendar
David Temkin
temkin at laszlosystems.com
Fri Sep 26 14:08:28 PDT 2008
I'd say that the tolerance-tightening you describe (starting with null
pointer dereferencing) is effectively an API/behavior change. That
particular change has been well documented in the porting guide that
was created with 4.0.
Is there similar documentation for the change in behavior when you
call non-existent methods/functions? Sounds like it must be, since the
underlying problem is probably the same but I don't remember reading
about that. If it's new to SWF9, but is different in DHTML, let's make
sure of it and document all of the behavior.
Method signature mismatch: Is it the case that this should not be a
compatibility issue (because of compiler magic), or is it a change in
behavior/API, like the null pointer derefencing, etc? If it is, then
it fits under the "tighter rules" rubric and should be documented.
(Limitations on states are in the same category). If this is a
"warning" condition rather than an error, with a prospect of becoming
an error down the road, then that too should be documented.
The technical choices for all of these were, I believe, 100% correct.
Performance is critical. But they need to be documented, and in one
place.
I still worry about the app changes. Many of them seem to have nothing
to do with the above. I would like to learn more from Josh or anyone
else changing the apps in the distro about what is being changed, and
why. We should understand everything that is not backward compatible,
including APIs, implicit behaviors, previously unenforced error
conditions, etc..
- D.
But clearly we have bug fixes here that have nothing to do with these
issues.
On Sep 25, 2008, at 2:47 PM, P T Withington wrote:
> You have a good point, and I think it would be great if Josh could
> try to summarize the nature of the changes he has had to make that
> were not outright bug fixes. If there are changes that reveal a
> lack of compatibility, we need to evaluate those.
>
> But, here's a question back at you: both the DHTML runtime and the
> SWF9 runtime are less forgiving that the swf8 runtime. For
> instance, in swf8, you can call a non-existent function, or access a
> non-existent variable, and it just happily moves on. Both DHTML and
> SWF9 consider these fatal errors. In a debug compile of swf8, you
> will get an error in the debugger, but in DHTML and SWF9, your
> program will just halt. We chose _not_ to try to emulate the
> lenience of swf8 in the other runtimes as we felt it would impose
> too much overhead. (I actually tried it in DHTML, but when yI did,
> the program was orders of magnitude slower -- too slow to even
> consider enabling it even in a debug build.) Was that not the right
> choice?
>
> I think that _some_ of the fixes that are being made are being made
> expediently to allow the applications to run at all, so they can be
> more thoroughly tested for other regressions, since most of our QA
> test plans involve running through the sample applications. If the
> application will not run at all, due to one of the errors I describe
> above, we can't do much testing.
>
> There is one other category of fixes that I know of that we have an
> outstanding task on: method signature mismatch. In LZX to date,
> there was no enforcement of overriding methods having to have
> equivalent method signatures, and no enforcement requiring the
> arguments to a method matching the parameters. The swf9 compiler is
> very strict about this (which has actually revealed a number of
> bugs). Our plan right now is to make the tag compiler 'fill in the
> gaps' when translating from LZX to JS, if it can, to keep the same
> flexibility we have always had. But again, in the short term, we
> are fixing these mis-matches in the test and demo applications so
> that we can use them for QA.
>
> On 2008-09-25, at 14:43EDT, David Temkin wrote:
>
>> Question about all of these demo app bugs that are being fixed on
>> an ongoing basis...
>>
>> The only code that I'd expect to change in the demo apps are the
>> comparatively few areas where LZX APIs are being changed. And yet
>> that's not what this looks like. It seems that either backward
>> compatibility is not what it's cracked up to be, or that pre-
>> existing bugs in the apps are being fixed (i.e., these are not
>> regressions).
>>
>> What are the app-level changes here, and why specifically are they
>> needed? Shouldn't the app continue to work from release to release
>> without these regressions?
>>
>> Developers using 4.2 are going to run into the same issues we are
>> when updating old code. If APIs, or behaviors/tolerance of existing
>> APIs are changing beyond what's been explicitly discussed, let's
>> get those out in the open.
>>
>> - D.
>>
>>
>> On Sep 25, 2008, at 9:42 AM, jcrowley at openlaszlo.org wrote:
>>
>>> Author: jcrowley
>>> Date: 2008-09-25 09:42:28 -0700 (Thu, 25 Sep 2008)
>>> New Revision: 11229
>>>
>>> Modified:
>>> openlaszlo/trunk/demos/calendar/cal-data.lzx
>>> openlaszlo/trunk/demos/calendar/infopanel.lzx
>>> openlaszlo/trunk/demos/calendar/selected-daylook.lzx
>>> Log:
>>> Change 20080925-laszlo-8 by laszlo at T43-L3XEXMW on 2008-09-25
>>> 03:52:43 EDT
>>> in /home/laszlo/src/svn/openlaszlo/trunk-bigboss
>>> for http://svn.openlaszlo.org/openlaszlo/trunk
>>>
>>> Summary: Remaining P0 Calendar fixes
>>>
>>> New Features:
>>>
>>> Bugs Fixed: LPP-6366 - SWF: Adding event and moving
>>> it to the next month causes extra events to be
>>> added to the calendar
>>> LPP-7042 - SWF9: Calendar: Cannot minimize day view
>>> LPP-7023 - SWF and DHTML: Calendar: Newly created
>>> event disappears if edit is canceled
>>> LPP-7017 - SWF8/9 and dhtml: Calendar: Data fields
>>> are blank in Add Event after creating/deleting
>>> multiple events
>>>
>>> Technical Reviewer: promanik
>>> QA Reviewer: henry
>>> Doc Reviewer: (pending)
>>>
>>> Documentation:
>>>
>>> Release Notes:
>>>
>>> Details: LPP-6366: This was actually a separate issue
>>> than the one described in the bug. Events weren't
>>> being dropped at the end of the month, but rather
>>> all over the place. Turns out currenteventDP
>>> wasn't getting updated to the current date, which
>>> was causing all kinds of confusion throughout the
>>> app.
>>> LPP-7042: Missing argument in a method was causing
>>> ActionScript errors.
>>> LPP-7023: Infopanel didn't recognize that an event
>>> was applied due to mistakenly setting "dataapply"
>>> to "false".
>>> LPP-7017: This was partially caused by my last
>>> change where I for whatever reason required the
>>> name of the event to be "New Event" before marking
>>> it as no longer selected prior to deleting it.
>>>
>>>
>>> Tests: Run Calendar in the SWFs and DHTML.
>>> LPP-6366: Move events back and forth. It's best
>>> to move it a week forward and then a week back
>>> from where it currently is. Before this fix, it
>>> would drop duplicate events all over the place.
>>> It should no longer do this.
>>> LPP-7042: In SWF9, click the button to switch to
>>> "day" view. Click the '-' button to minimize.
>>> It should now let you shrink the day without
>>> freezing the app.
>>> LPP-7023: Click "New Event". Name event something
>>> and click "Apply". Close the info panel. Open it
>>> again by clicking the 'i' button on the event.
>>> Close the event again. It should no longer make
>>> the event disappear.
>>> LPP-7017: Create an event and name it "Event 1".
>>> Do the same twice more and name each one something
>>> else, closing the info panel between each. Delete
>>> each one one at a time. When all are gone, create
>>> a new event. All inputtext fields should be in
>>> infopanel as expected.
>>>
>>>
>>>
>>>
>>> Modified: openlaszlo/trunk/demos/calendar/cal-data.lzx
>>> ===================================================================
>>> --- openlaszlo/trunk/demos/calendar/cal-data.lzx 2008-09-25
>>> 14:58:35 UTC (rev 11228)
>>> +++ openlaszlo/trunk/demos/calendar/cal-data.lzx 2008-09-25
>>> 16:42:28 UTC (rev 11229)
>>> @@ -205,13 +205,16 @@
>>> getNewNode(alleventsDP,'day'+day);
>>>
>>> tempDP.setFromPointer( currenteventDP );
>>> + tempDP.setNodeAttribute('selected', 'false');
>>> // Copy current data to new location
>>> // If the record being moved is selected (usually the
>>> case,
>>> // currenteventDP changes after this call
>>> var newPoint =
>>> alleventsDP.addNodeFromPointer(currenteventDP);
>>> + currenteventDP.setFromPointer(newPoint);
>>>
>>> //Delete the original node
>>> tempDP.deleteNode();
>>> + currenteventDP.setNodeAttribute('selected', 'true');
>>>
>>> // Set the event data pointer to the top of the event data
>>> alleventsDP.setXPath('eventdata:/vcalendar[1]');
>>> @@ -220,9 +223,7 @@
>>>
>>> <method name="deleteEvent">
>>> // Deletes the current node
>>> - if(currenteventDP.xpathQuery('summary/@value') ==
>>> "New Event"){
>>> - currenteventDP.setNodeAttribute("selected",
>>> 'false');
>>> - }
>>> + currenteventDP.setNodeAttribute("selected", 'false');
>>> currenteventDP.deleteNode();
>>> //currenteventDP.setXPath('blankEvent:/event[1]');
>>>
>>>
>>> Modified: openlaszlo/trunk/demos/calendar/infopanel.lzx
>>> ===================================================================
>>> --- openlaszlo/trunk/demos/calendar/infopanel.lzx 2008-09-25
>>> 14:58:35 UTC (rev 11228)
>>> +++ openlaszlo/trunk/demos/calendar/infopanel.lzx 2008-09-25
>>> 16:42:28 UTC (rev 11229)
>>> @@ -70,7 +70,7 @@
>>>
>>> <!-- CLASS: info_Panel
>>> =============================================== -->
>>> <!--
>>> =================================================================
>>> -->
>>> - <class name="info_Panel" extends="basepanel" clip="true"
>>> onclick="Debug.write(this.datapath)">
>>> + <class name="info_Panel" extends="basepanel" clip="true">
>>>
>>> <attribute name="opened" value="false"/>
>>> <attribute name="dataapply" value="false"/>
>>> @@ -111,8 +111,10 @@
>>>
>>> var prevcell = 'cell' + Number(thiscell
>>> - 1);
>>> if(thiscell > 1){
>>> -
>>> calgrid.daySelectionMgr.select(global[prevcell]);
>>> - calgrid.open_day =
>>> global[prevcell];
>>> + if(typeof global[prevcell] !=
>>> 'undefined'){
>>> +
>>> calgrid.daySelectionMgr.select(global[prevcell]);
>>> + calgrid.open_day =
>>> global[prevcell];
>>> + }
>>> }
>>> eventDataMgr.changeDay(-1);
>>> if(thiscell == 1){
>>> @@ -138,8 +140,10 @@
>>>
>>> var nextcell = 'cell' + Number(thiscell
>>> + 1);
>>> if(thiscell < 42){
>>> -
>>> calgrid.daySelectionMgr.select(global[nextcell]);
>>> - calgrid.open_day =
>>> global[nextcell];
>>> + if(typeof global[nextcell] !=
>>> 'undefined'){
>>> +
>>> calgrid.daySelectionMgr.select(global[nextcell]);
>>> + calgrid.open_day =
>>> global[nextcell];
>>> + }
>>> }
>>> eventDataMgr.changeDay(+1);
>>> if(thiscell == 42){
>>> @@ -347,7 +351,7 @@
>>> slideclose1.doStart();
>>> slideclose2.doStart(); //remove
>>> this.opened = false;
>>> - this.setAttribute('dataapply', false);
>>> + this.setAttribute('dataapply', true);
>>> ]]>
>>> </method>
>>>
>>>
>>> Modified: openlaszlo/trunk/demos/calendar/selected-daylook.lzx
>>> ===================================================================
>>> --- openlaszlo/trunk/demos/calendar/selected-daylook.lzx
>>> 2008-09-25 14:58:35 UTC (rev 11228)
>>> +++ openlaszlo/trunk/demos/calendar/selected-daylook.lzx
>>> 2008-09-25 16:42:28 UTC (rev 11229)
>>> @@ -20,7 +20,7 @@
>>> calgrid.locked=true;
>>>
>>> calgrid.gridlayout.setopenview(null,false);
>>> calgrid.locked=false;
>>> - calgrid.showmonthview();
>>> + calgrid.showmonthview(true);
>>> } else
>>> calgrid.gridlayout.setopenview(null,true);
>>> }
>>> </handler>
>>>
>>>
>>> _______________________________________________
>>> Laszlo-checkins mailing list
>>> Laszlo-checkins at openlaszlo.org
>>> http://www.openlaszlo.org/mailman/listinfo/laszlo-checkins
>>
>
More information about the Laszlo-dev
mailing list