Fifth Client Meeting

Hi,

Well, actually, the meeting went better than I had previously expected.  However, there was a LOT that could have gone better.

Notably, the serializer and deserializer worked pretty well, with issues.

Somehow, the parser didn't work at all.  This is problematic, particularly since I didn't change the code since last night, when it did.  This means that someone changed the code so that it's passing in garbage to the parser, so it either gives a warning and crashes, or produces erroneous output.  I was very disappointed in this.  It should have worked perfectly, and I was looking forward to showing it off.

That said, at least internally, we have a proof of concept.  As a group, we know all of the technology in play will be fundamentally valid.  It's just a matter of getting it to work properly.

Let's do this.

Ian

Updates

Hi,


So, the serializer and renderer are not completed.  Those were my areas of responsibility.  While I think that the fact that they are not yet completed is a product of factors that aren't all of my doing, I personally said I would get these done, so it's ultimately my fault.  If worst comes to worst, I'll take the blame for it.

Now.  Not all is lost, of course.  The deserializer is coming along.  That will need to be finished.  The serializer *should* be done already.

As far as rendering, I am pleased to announce that the key link between GWT's retarded API and my HTML parser has been discovered (albeit through some particularly nasty recursion)!  As a result, the renderer can now take a canvas and spit out HTML that corresponds to it.  It's not perfect, but I think it will satisfy for tomorrow (next client meeting).  As proof, see this HTML file from the generator: http://cs.unm.edu/~imallett/other/460/Untitled-2.html.

Thanks,
Ian

Serializer and Converter

Hi,

I finished the basics of the serializer.  It serializes all children.  A couple of fields are still incorrect, but they're not as important.  I subsequently released control of the module to the group to improve.

Now, as far as the HTML converter is going, it's not.  Don't get me wrong; the parser, formatter, and synthesizer described here: http://iancs460.blogspot.com/2012/03/revised-parser.html are all working perfectly!  The renderer just isn't.  Right now, all that's happening is the renderer is calling "canvas.getElement().getInnerHTML()".  This produces the final output:

<html>
  <head>
    <title>
      [PAGE TITLE HERE]
    </title>
  </head>
  <body>
    <div id="isc_7P" eventproxy="isc_WebPage_0" class="normal" style position: relative; z-index: 201872; visibility: hidden; background-image: url(http://1.bp.blogspot.com/-h-aleanaggc/tcbtz8mgaai/aaaaaaaaalq/hofsrycnkle/s320/checker.png); overflow-x: visible; overflow-y: visible; left: 5px; top: 5px; width: 1373px; height: 936px; background-repeat: repeat repeat; onscroll return isc_webpage_0.$nd()>
      <div id="isc_7Q" eventproxy="isc_WebPage_0" style="POSITION:relative;VISIBILITY:inherit;Z-INDEX:201872;CURSOR:default;">
        &nbsp;
        <div id="isc_7R" eventproxy="isc_Canvas_17" class="normal" style="POSITION:absolute;LEFT:0px;TOP:0px;WIDTH:1373px;HEIGHT:902px;Z-INDEX:201890;OVERFLOW:visible;" onscroll return isc_canvas_17.$nd()>
          <div id="isc_7S" eventproxy="isc_Canvas_17" style="POSITION:relative;VISIBILITY:inherit;Z-INDEX:201890;CURSOR:default;">
            &nbsp;
          </div>
        </div>
        <div id="isc_7T" eventproxy="isc_Canvas_16" class="normal" style position: absolute; z-index: 201908; overflow-x: visible; overflow-y: visible; left: 0px; top: 0px; width: 1373px; height: 936px; onscroll return isc_canvas_16.$nd()>
          <div id="isc_7U" eventproxy="isc_Canvas_16" style="POSITION:relative;VISIBILITY:inherit;Z-INDEX:201908;CURSOR:default;">
            &nbsp;
            <div id="isc_7V" eventproxy="isc_WebPageCanvas_3" class="header" style position: relative; z-index: 201926; overflow-x: hidden; overflow-y: hidden; left: 0px; top: 0px; width: 1373px; height: 135px; onscroll return isc_webpagecanvas_3.$nd()>
              <div id="isc_7W" eventproxy="isc_WebPageCanvas_3" style="POSITION:relative;VISIBILITY:inherit;Z-INDEX:201926;CURSOR:default;">
                &nbsp;
              </div>
            </div>
            <div id="isc_7X" eventproxy="isc_WebPageCanvas_4" class="body" style position: relative; z-index: 201944; overflow-x: hidden; overflow-y: hidden; left: 0px; top: 10px; width: 1373px; height: 722px; onscroll return isc_webpagecanvas_4.$nd()>
              <div id="isc_7Y" eventproxy="isc_WebPageCanvas_4" style="POSITION:relative;VISIBILITY:inherit;Z-INDEX:201944;CURSOR:default;">
                &nbsp;
              </div>
            </div>
            <div id="isc_7Z" eventproxy="isc_WebPageCanvas_5" class="footer" style position: relative; z-index: 201962; overflow-x: hidden; overflow-y: hidden; left: 0px; top: 20px; width: 1373px; height: 45px; onscroll return isc_webpagecanvas_5.$nd()>
              <div id="isc_80" eventproxy="isc_WebPageCanvas_5" style="POSITION:relative;VISIBILITY:inherit;Z-INDEX:201962;CURSOR:default;">
                &nbsp;
              </div>
            </div>
          </div>
        </div>
      </div>
    </div>
  </body>
</html>

This looks pretty good, but it doesn't render anything else.  I suspect this may be due to it's not calling the same on its children?  In which case, the fix might be simple.  If not . . .

See also: http://stackoverflow.com/questions/9855735/get-smartgwt-canvas-as-html

Ian

Progress

Hi,

Well, we're making progress.  On the serializer, the correspondence between the input and the output is nearly one-to-one in the ways that matter.  The problems are the "left" data field is not being set, and the children are not being serialized.

I don't know why the first is the way it is, but the second is due to me simply not implementing it yet because it's hard.  However, I'm about to go do that now.  Hopefully by tonight or tomorrow evening the "serializer"/"deserializer" will do everything it needs.

I'd also like to note that Nialls has done a nice job improving our home page.  There are now joke testimonials and a cleaner layout.  I think I might like to work on some web design soon, seeing as the algorithms section of this project is nearly wrapped up.

Ian

"Serializer" Hacks

Hi,

Well, GWT is broken and buggy as ever.  For instance, the methods .getEdgeSize() and .getExtraSpace() both fail on a newly created canvas with a NullPointerException.  Turns out that typing too fast (e.g., my auto log-on script) can crash GWT, as well as certain properties.  GWT at least catches errors and gives you nice feedback if you do some things (like call some methods after construction).  Though, I'm not sure how you call a message before construction?  And yes, GWT still crashes every now and again, which is . . . disconcerting.

The API is inconsistent between the getters and setters, which made matching everything up a huge ordeal.  Not to mention that the API has (literally!) about 200 getters and setters.  Not all of them are necessary, probably--but how am I to know?  The code is horribly messy (notably because Java doesn't have function pointers, nor macros) too.

It does kinda remind me, though, of how slow the whole thing is.  GWT takes forever to start, then the website has to load up.  Then you have to click login, wait for the window to come up, enter your username/password, click send, wait for that to go through, open a new project, and *then* you can click "save", and actually run a single test!  Our code isn't exactly slow per-se; the process to do something is just soooo long!

In any case, after much complaining and whatnot, the serializer/deserializer kinda works.  A canvas can be taken in, serialized, and then deserialized.  I don't know if the correspondence is one-to-one in the important ways (except for what I know isn't, like recursively evaluating children), but it's a strong start.

Tomorrow (today) I'll finish it up.  I DO have other classes too, so I'll need to work on that as well.  It's just about 1:45AM, so, knocking off for the night.  See you bright and early.

Ian

Serialization Update 2

Hi,

Well, the serialization fiasco has mostly been figured out.

It turns out that yes, my serializer does work.  Moreover, it works perfectly, and everything would be good . . . except that the deserializer does not.  As it happens, Java's deserialization is, put simply, broken.  There's nothing for it.  In real life (C++) I'd use a copy constructor, and that would be the end of it, but Java apparently can't handle that.

Unfortunately, the deserializer doesn't, and can't work, unless the GWT designers had thought of it, which they didn't.  We'd be stuck, except Joe Collard put into words what I was coming to the realization was necessary (on same post by Nialls mentioned previously, here): "see if you can write a wrapper that contains all of the things you will want saved".

Essentially, the idea boils down to: write your own serializer.  It's bloody messy, but Java's (de)serialization is broken and reflection isn't supported by GWT.  So, we have to go with it.

No private/protected fields can, of course, be serialized.  Hopefully this shouldn't be an issue.  It appears to have worked for Joe's group, so hopefully it will work for ours.

Ian

Serialization Update

Hi,


So, when running the serializer, GWT will produce errors:

[ERROR] [web_final] - Errors in 'file:/C:/dev/Java/CS%20460%20Project/Web_Final/src/cs460/webdnd/client/utilities/serialization/serializer.java'
 [ERROR] [web_final] - Line 24: No source code is available for type java.io.ByteArrayOutputStream; did you forget to inherit a required module?
 [ERROR] [web_final] - Line 25: No source code is available for type java.io.ObjectOutputStream; did you forget to inherit a required module?
 [ERROR] [web_final] - Line 39: No source code is available for type java.io.InputStream; did you forget to inherit a required module?
 [ERROR] [web_final] - Line 39: No source code is available for type java.io.ByteArrayInputStream; did you forget to inherit a required module?
 [ERROR] [web_final] - Line 40: No source code is available for type java.io.ObjectInputStream; did you forget to inherit a required module?
 [ERROR] [web_final] - Line 47: No source code is available for type java.lang.ClassNotFoundException; did you forget to inherit a required module?


In response to this, Nialls took over serialization/deserialization using code he found online.  This code produces tons of errors, as he writes here: http://niallsc.blogspot.com/2012/03/canvas-serialization-status-failed.html.


However, this misses something--my serializer worked.  It produces this output (if you add a print statement):

Now, this looks to me like taking a canvas and serializing it (and I can get a canvas back, deserializing it).  I'm not sure what the problem is with Nialls's code, but mine seemed to work.

I feel somewhat accused, but I submit the above as evidence that the code I wrote is working properly.  There were limited tests with more complex canvases (nested, with content, etc.) that were conducted some time ago, successfully.  It is possible that there is some new problem (like maybe a certain component can't be serialized) which can be solved in the same way as the canvas's serialization was.

Now, I don't know what to say.  Maybe there's something subtle going on that I'm missing.  Maybe I don't know what I'm talking about.  Maybe there's a fundamental flaw in this that really will somehow prevent this from working.  I welcome explanations.

Regardless, I think it's a good idea to meet Sunday as Nialls suggested to work this out.  For the good of the project, it needs to be solved sooner rather than later--and I had already thought it was solved.

Thanks,
Ian