I am looking to replace some browser instances in a WPF application. Currently they are using IE which I believe is causing major memory leaks. I have found three options: CefSharp, CefGlue and Awesomium. The first two seem to be lower level implementations whereas Awesomium seems to be what I am looking for.
The deal breaker so far is I can't find a sane way to do a HTTP post. I find the following answered question:
Awesomnium Post Parameters
This options seems insane, I have to register a single instance of a RequestInterceptor to do a post? I am looking for another option, otherwise I think CefGlue is the next best bet.
Related
Using JOOQ version 3.13.4
I don't like the ASCII table formatting that the Record.toString() method does.
It's particularly unhelpful in the IDEA debugger view:
But I also don't like dumping needless multi-line strings into my prod logs - which I usually avoid doing; partially for obvious speed/size reasons, but also because they're ugly and hard to read in most log viewer apps (CloudWatch etc.)
I found the Github issue that implemented the ASCII table: https://github.com/jOOQ/jOOQ/issues/1806
I know I can write code to customise this, but I'm wondering if there's a simple flag/config I'm missing to get a simple summary (if I ever got around to writing my own, I'll use JSON)?
The current formatted ASCII table is quite useful for most debugging purposes, which include simple println() calls, Eclipse's debugging view (see below), etc. This includes showing only the first 5 records in a Result for a quick overview, and Record classes work the same.
The feedback from the community has generally been good for these defaults, but if you want to challenge them, try your luck here, and see if your feature request gets community upvotes: https://github.com/jOOQ/jOOQ/issues/new/choose
Eclipse's variable view:
As you can see, with the detail view, it's much less of a problem in Eclipse. I've always found it surprising IntelliJ didn't copy this very useful feature from Eclipse. Maybe, request it?
I know I can write code to customise this
I'll document it here nonetheless, as future visitors will no doubt find this useful.
IntelliJ has a lot of "smartness" in its debugger's variables view, sometimes a bit excessive. For example, an org.jooq.Result just displays its size(), because a Result is a List. I guess it's smart to hedge against excessive efforts if JDK lists are too long, though jOOQ results can handle it, and otherwise it would be possible to display list.subList(0, Math.min(list.size(), 5)) + "...".
Luckily, you can easily specify your own type renderers in IntelliJ, for example this one:
It uses this code to render a jOOQ Record:
formatJSON(new JSONFormat()
.header(false)
.recordFormat(JSONFormat.RecordFormat.OBJECT)
)
The output might look like this:
You might even suggest this as a default to IntelliJ?
but I'm wondering if there's a simple flag/config I'm missing to get a simple summary (if I ever got around to writing my own, I'll use JSON)?
No, there isn't, and I doubt that kind of configurability is reasonable. People will start requesting 100s of flags to get their preferred way of debugging, when in fact, this can be very easily achieved in the IDE as shown above.
Again, you can try your luck with a change request to change it for everyone, but a configuration for this is unlikely to be implemented.
According to the occurrence of questions about 'AutoMapper Migraton from static API' lately and the fact I was Exploring Christos Sakell blog 'Building Single Page Applications using Web API and AngularJS', I also came across some obsolete warnings.
/***********************************************************************************
* AutoMapper.Mapper.CreateMap()' is obsolete: 'Dynamically creating maps will be removed in version 5.0.
* Use a MapperConfiguration instance and store statically as needed, or Mapper.Initialize.
* Use CreateMapper to create a mapper instance.
***********************************************************************************/
Completely ignorant of recent changes of AutoMapper (I using this mapping tool for the very first time) I was trying to get rid of those obsolete messages. Searching around I came across two possible solutions:
1) http://quabr.com/36398318/automapper-mapper-createmaptsource-tdestination-is-obsolete , and
2) http://davecallan.com/automapper-4-2-example/#comment-8914
These hints seemed to be pretty straightforward. It turned out tweaking the *MappingProfile classes weren't that difficult, but what to do on several controllers? That was a complete different piece of cake. I got completely lost. I ran in all kind of strange errors not knowing or having a clue what to do. Even the just mentioned blogs weren’t that explanative. More or less, I got the feeling they were keeping the puzzle a live (I'm kidding).
So the question was: how to solve the troublesome mapping from the controller to the *MappingProfile class. Luckily, I found a possible solution, so please tackle it...
I do like puzzling and buzzing around the net, I finally found a combination of hints, and that's what I want to share with you.
The solution for this is a combination of tweaks.
First of all, have a look at page 'Migrating from static API' (https://github.com/AutoMapper/AutoMapper/wiki/Migrating-from-static-API).
Notice the second block right below ‘In 4.2.x and later …’ that’s what is needed on several controllers. Dave Callan just gave a part of the clue. He just forgot a part of the solution. So I asked him to add the missing part to his solution as well.
So, implementing the hint on the 'Migrating from static API' page in combination with the suggestion of Dave Callan (http://davecallan.com/automapper-4-2-example/#comment-8919) block 1: Instantiating a new MapperConfiguration(...) in *MappingProfile class(es), you can get rid of those obsolete warnings: On every cycle proper mapping.
At least, I got rid of those warnings.
What will happend in the nearer future with AutoMapper, hopefully those guys in Austin TX will make proper decisions on this matter.
I also testing the code (block 2 of 'Migration from static API') with the suggestion on Quabr (instead of instantiating a new MapperConfiguration, they suggest to call the Initialize method of the current Mapper). This combination gave my errors like ‘index outside matrix borders’.
Apparently on each cycle the mapping lists are not renewed. This combination of code tweaks resulted (to me) in a ‘no go’. Perhaps others, do not agree with me, fine, at least that’s what I noticed.
My only goal is to help other members who are facing comparable trouble.
I'm pleased to share my solution. Have fun
One of the barriers (that as far as I know was never removed, but perhaps I'm mistaken and this was resolved a while ago?) to being able to have truly cross browser compatible tests with Watir and Firewatir is that Watir was originally designed to use One based indexing, while whoever created firewatir broke with that and made it Zero based.
While I'm sure there are good historical reasons for each decision, and I don't want to debate which is right, it's been a pain for testers trying to create scripts that run under each without any alteration since at the very least this affects identifying elements by :index, which is sometimes something you've no choice but to do.
I'm wondering if moving to Watir-Webdriver could create a more uniform platform?
Also do we have any reference to the differences between the latest Watir, and Watir-Webdriver? For example in a recent question here it came up that .value= is not implemented as a 'direct set without events' alternative to .set, and basically acts just the same as .set does.
The best solution to this problem would be for Watir 1.X to gain configurable indexing. I believe the majority of that work has already been done on Bret's zero-index branch, so it's just a question of someone picking that up and getting it out there.
When we were migrating to watir-webdriver, we added this monkey patch to help with this problem:
class Fixnum
def as_index
Config.webdriver? ? self - 1 : self
end
end
and then in our scripts:
browser.div(:index => 1.as_index)
Then when we were off Watir completely, it was a simple matter of grepping for as_index throughout the code base and decrement the indexes by one.
I've tried to document the major differences between Watir and watir-webdriver on this wiki page. I'm sure it's lacking, and if someone wants to improve it, that's very welcome of course :)
My question will be hard to form, but to start:
I have an MFC SDI app that I have worked on for an embarrassingly long time, that never seemed to fit the Doc/View architecture. I.e. there isn't anything useful in the Doc. It is multi-threaded and I need to do more with threading, etc.
I dream about also porting it to Linux X Windows, but I know nothing about that programming environment as yet. Maybe Mac also.
My question is where to go from here?
I think I would like to convert from MFC Doc/View to straight Win API stuff with message loops and window procedures, etc. But the task seems to be huge.
Does the Linux X Windows environment use a similar kind of message loop, window procedure architecture?
Can I go part way? Like convert a little at a time without rendering my program unusable for long periods of work?
Added later:
My program is a file compare program (sounds simple enough.) So, stating my confusion in a simple way, normally a document can have multiple views, but in this app, I have one view with multiple (two) documents (files). I have a "compare engine" that I first wrote back in the DOS days, that is the heart of the program and the view is just looking at the output of that routine. Sometimes I think that some of my "view" code could make sense in a "document" class but I hardly know where to begin to separate it into more classes. I have recently started reading "Programming Windows" 5th Ed. by Charles Petzold, (I know that is quite out of date (C) 1998) hoping to get a better understanding of direct Windows programming.
I get overwhelmed with the proliferation of options like C#, NET, MFC, MVC, Qt, wxWidgets, etc.
I find I am often stuck trying to understand something going on in the MFC framework because something in my code doesn't work as it seems it should, but the problem is that I don't really understand how MFC is handling things in the background. That is why I am trying to learn "straight Windows programming" where my program has all the message passing code that I write. I hope this helps give enough insight into my question so someone can guide me on my way.
X works enough differently that a raw Windows program and a raw X program probably wouldn't be able to share much UI code at all.
If you want portability between the two, chances are pretty good that you want to use something like Qt or wxWidgets. Of the two, wxWidgets is more similar to MFC, so it would probably require less rewriting, but would maintain (more or less) the same "disconnect" you're seeing between what you want and what it provides.
Without knowing more about your application, and why it doesn't fit well with MFC, it's impossible to guess whether Qt would be a better fit or not. An immediate guess would be "probably not".
MFC uses a "document/view" architecture, where Qt uses the original Model-View-Controller architecture. For the most part, MFC's Document class is equivalent basically a Model and a Controller rolled into one -- so if your Document contains nothing useful, in Qt you'd apparently have both a Model and a Controller, neither of which did much that was useful.
That said, I have to raise a question about why your Document currently doesn't do much. The MVC pattern has proven applicable to a wide variety of problems, so while it's possible it can't work well for your problem, it's also possible that it could work well, and you're simply not using it. Without knowing more about what you're doing, it's impossible to even guess at that though.
Edit: Okay, the clarification helps quite a bit. The first thing to realize is that a Document does not necessarily equate to a file. Quite the contrary, a document can perfectly reasonably relate to an arbitrary number of files.
Just for example, consider a web browser. All the data needed to compose the page its currently displaying would reasonably be part of the same document. Depending on your viewpoint, that's either zero files, or a whole bunch of them (it will start as an arbitrary number of files coming from the server(s), but won't necessarily be stored as files locally at all). Storing any of it as a file locally will be a (more or less) accidental by-product of caching, and mostly unrelated to browsing per se.
In your case, you're presumably reading the two (or three?) files into memory and storing them along with some sort of data structure to hold the result of the comparison. After the comparison is complete, you might or might not discard the contents of the files themselves. I think it's safe to say that the "normal" separation of responsibilities would be for that data and the code that produces that data to be in the Document.
The View should contain only the code to take that result from that data structure, and display it on screen. Nearly the only data you normally want to store in the View would be things related to how the data is presented (e.g., things like a zoom level or current scroll position). Likewise, the code in the view should relate only to displaying the result and reacting to user input, NOT to "creating" the data in the first place.
As such, I think your program could be rewritten to use the Document/View pattern more effectively, or could be rewritten to use MVC. That, in turn, means a port to Qt could/would probably work just fine -- provided you're willing to put some time and effort into understanding how it's intended to work and then make what may be fairly substantial changes to your code to work the way it's designed to.
As I commented previously, wxWidgets is more like MFC in this respect -- it uses a Document and View, not a Model, View, and Controller. It's also going to work best if you do some rewriting to separate responsibilities the way it's designed for. The good point is that it's probably a bit easier to do that one step at a time: rewrite the code in MFC, which which you're already familiar, and then port it to wxWidgets -- but given the similarity between the two, that "Port" will probably be little more than minor editing -- often just changing some names from C* to wx* is just about enough. To my recollection, the only place I've run into much work was in creating menus -- with MFC they're normally handled via resources, but (at least a few years ago when I used it) wxWidgets normally directly exposed the code that created the menu entries.
Porting to Qt would probably be more work -- you pretty much have to learn a new framework, and substantially reorganize your code at the same time. The good point is that when you're done, the result will probably be somewhat cleaner, though given what you're doing, the difference may be pretty minor. In a Document/View, the View displays data, and reacts to user input. In a Model/View/Controller, the View only displays data, but user input (that modifies the underlying data) goes through the Controller. Since you (presumably) don't expect to modify the underlying data, the only user input involved probably belongs in the view in any case (e.g., things like scrolling). It's barely possible you might have a few things you could put in the Document/Model that would be open to change (e.g., things like the current font or colors the user has selected).
I've been evaluating different Java Web Application UI Frameworks. I have about 8 months of intensive JSF experience that I'd like to continue using. JSF also provides me the spider-readable markup as well as the ability to create very simple forms without touching much Java code.
I also will have need for thick-client side interfaces that will perform well with few server round trips. GWT seemed like an ideal choice for this.
So, when I found G4jsf, I thought I had found the best of both worlds. However, I can't seem to find any active development on it. I hope it hasn't died, but it seems like that is the case.
Is there active development on this? Or am I two years too late?
Well, based on the conversation in the reference below, it seems that G4jsf is no longer being supported. If the poster is in fact Sergey Smirnov, I would imagine he'd be a pretty reliable source on the matter. :)
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=150674