So one of the neat features of languages like PHP is that you can include other files pragmatically and make a plugin-like system. I haven't seen an example of it yet, so I am not sure it is technically possible in Dart, but I would like to start designing a CMS that can load and unload plugins live without restarting or a fresh upload.
Currently it is only possible to load/unload code dynamically using Isolates.
In the browser new isolates don't have access to the DOM and it is limited which types can be passed between isolates. What can be serialized to JSON can be passed between isolates easily but for custom types you need to serialize yourself. I'm not sure about the actual limitations here though, this is work in progress.
In the browser the current limitations make it hard to make use of isolates. You can't load code into an isolate that imports 'dart:html' this prevents the use any browser API. On the server there are no such limitations.
This should all be improved but currently there are still a lot of limitations.
Related
So far I built most of my UI and logic in QML with JavaScript without touching the C++. But now I need to make a RESTFul API call, based upon the examples I saw so far I must write the call code in C++ then "some how" (Am still figuring out that part) get it in the QML/JavaScript world....
Can't i make the API call etc completely etc in QML/JavaScript?
I am not an expert in REST but in theory if you could write the call in JavaScript running in a browser, you should be able to make the the same call using very similar JavaScript in QML/JS.
Having said that one of the things you want to do to maintain the responsiveness of your application is not run any time consuming routines on the event thread. Ensuring this is the case is quite easy in C++, I'm nos sure you could do that as easily in JS.
Finally it is relatively easy to get the results back to JavaScript world is quite easy. Qt and Cascades has a rich data modeling component set. QVariantList and QVariantMap types map into JS arrays.
I like what I read about Lift, and I like the concept of Dart, but have little experience in both to be able to decide if thinking about using them in the same project is even making sense.
I want both writing structured client side code, and not having to worry about the OWASP top 10 as much
Can they work together? Does it make sense at all? Did anyone try?
I have integrated Dart with Lift using REST services together with Dart's XmlHTTPRequest and liked the result. I would say that any web framework that makes making RESTful services as easy as Lift does is a perfect match for Dart. On the other hand web frameworks such as JSF which requires components to take part of a advanced life cycle are probably not a good fit.
That being said, having the same language on the client and the server side is definitely a win, so when the Dart VM matures a bit more and starts to include RESTful functionality similar to what Express does for NodeJS then I would probably use that instead.
Already now baby steps are being taken for including HTTP support in Dart semilar to what Node provides on V8. Another important point for Dart is that it allows the browser and server to share rich objects, like what GWT does for Java, and this should further ease building advanced web applications with Dart.
I find no documentation on how to update objects vaadin asynchronously. Can anyone help me? What I need is to render a table and then update the values of a column with a call rather slow, and so I want to make it asynchronous ..
This has been discussed a lot on this thread on the Vaadin forum. You might want to read it, it contains a lot of useful information.
Just do the updates in another thread. UI modifications from background threads must be synchronized to application object. Add icepush, refresher or proggresbar to get changes from server to client.
As far as I know Vaadin provides two add-ons for solving this problem: ServerPush and DontPush. Both add-ons can be imported via maven and both support WebSockets as well as fallback solutions for browsers without WebSocket support. Although ServerPush provides seemingly more features than DontPush, it is lower rated than DontPush, probably because it is more complicated.
For pushing updates to the client DontPush provides a very simple solution that does not require any changes to the web application. Only the servlet-class in web.xml needs to be replaced by org.vaadin.dontpush.server.impl.jetty.DontPushServlet and the widget set has to be updated afterwards via mvn vaadin:update-widgetset. That's all. Any changes on the server will be automatically pushed to the client. I successfully tested this add-on with Chrome 14. Unfortunately, I could not get it working with Firefox 7.
According to the web page of ServerPush the ServerPush add-on should provide this functionality, too. However, I could not figure out how to setup ServerPush to be working with jetty. Moreover, it seems to be more complicated in use. It requires several changes to the web.xml as well as additional configuration files for the atmosphere server.
In contrast to DontPush ServerPush provides also an explicit pushing mechanism which allows to update the GUI manually by calling the push() method of a certain pusher component which needs to be added to the main window beforehand. However, I also failed to get this working.
I'm pretty new to static libraries. I recently created one library because I have a lot of source code, and the updates of my projects ended as a nightmare.
So, this is a static library for iPhone.
My question is quite simple : I use this library for me and my company. But, how can I use a portion of it to make projects for my clients ? For example, I have a class which reads PDF or Photos, depending of the initialization parameters.
I don't want my client able to use the photo part, just by seeing the headers. How can i achieve that ? I thought to remove some parts of the headers i will give to my client, but i'm pretty sure there are better options.
Thanks
Presuming you are using objective C code, it will not be enough to just remove the headers since a smart client will be able to "ask" the code about its interface by using class-dump.
So if you want to be certain that the code is not available to your clients, you need to remove it completely from your static library.
Update:
CocoaReverseEngineering provides information about how to access the hidden information in frameworks and libraries. But you can also use it so you know what's possible and thus preventing it happening.
I've been thinking about this recently and I don't know a really nice and tidy way of creating a mobile version of an existing or new MVC2 website/app.
I think the easiest way would be to just use a different stylesheet depending on whether a mobile was detected but sometime you need to change the view content too if you have massive inline images everywhere or for other reasons.
What is a good approach for this? Is there a way of theming fairly easily in MVC2?
Well MVC is just your server-side technology, what you should ask to yourself is "what is the best practice to create a mobile web site, regardless of the server side tech".
In my opinion, creating a well-formed and semantic (x)html is the first step. As you say, the most logical thing to do is create different style sheets for different media types, and you're right.
As for the problems you mention, like inline images, consider this: are those images content or presentation?
In the first case, they should be present even in the mobile version.
In the latter, they are defined in the style sheet, so you can simply avoid them in the mobile css.
The only exception I can think of is when you want to provide different functionality on mobile, or if you're forced to, i.e. on pages that rely heavily on JS and those scripts wouldn't run on mobile browsers. In this case, you might want to create different versions of those pages and serve the appropriate version based on the user agent.
Check the source code for NerdDrinner. They've implementated a MobileCapableWebFormViewEngine class which inherits from base WebFormViewEngine class. The MobileCapableWebFormViewEngine uses the HTTPContext to decide which View to render in the client. This'll make more sense when you see the source code