(Warning: This may be a stupid question...)
I am am one of those who are not willing to move to SubSonic 3.0. I am currently using a customized fork of SubSonic 1.(?). I want to migrate to version 2 for many reasons, and I have been successfully been playing with Subcommander. Cool stuff! Here's my question...
When I generate the DAL for 2 databases, when I put those DAL files into the same project, with SubSonic 2.2 allow me to connect to both of them in the same project/application at the same time?
Yes you can, but they will need to be in separate namespaces (I think). I've done it and I found that giving each its own project and namespace was the easiest to manage - especially with subcommander since each project can have its own config file.
You may also want to take a look at the SubStage application. I found it great for discovering the myriad of settings available with SubSonic code generation.
Multiple database support was first introduced with SubSonic 2.0 Beta 1. It is hard to find samples online, but the Starter Site project is still a good reference as it includes two database references. You can find the source on Google Code.
Related
Currently I'm developing a Java 8 / JavaEE 7 Web application using JSF 2 with Primefaces 6.
As a part of this project, I have to build a module to fetch translations (messages in German and English) from a database to get a dynamically translated application since hard coding Strings simply isn't an option.
After two days of reading stuff about ResourceBundles, ResourceBundle.Controls and ResourceBundleControlProvider I completely lost understanding of the whole matter.
I found many possible solutions that were about two to three years old, which were always completely different, which is why I came to ask my question here. I know that there are some posts here that describe some cases but I would be glad if someone could help me understand this matter.
Could anyone explain the usual workflow or state-of-the-art method to solve my problem and give an explanation of the important classes used for the solution?
If anyone ever encounters the same issue as me, after days of searching and tinkering around I found a website that provides a very neat tutorial to achieve i18n in a JSF application with localized strings from a database.
This guide explains the needed steps one after another and worked pretty well for me.
https://zenidas.wordpress.com/recipes/database-resource-bundle-in-a-jsf-application/
The basic steps to be done are as follows:
Create the resource bundle extension that will delegate the resources lookup in a database control
Create the necessary extensions for different locales
Create the database tables and the corresponding JPA entities
Create the resource bundle control that will get the contents from the database
Define the resource bundle in the faces-config file
After those steps it should be possible to access the localized data from the database, if there are some difficulties I'd recommend to test the database access itself independent of the resource bundles.
Hopefully this will be useful to someone, someday.
I am planning to upgrade my company's intranet from liferay 6.0.6CE to 6.2CE. I have done some research on it but I am still confused on API part. Will my custom portlets need only recompilation or would they need a complete rewriting. I am also concerned about my Theme and Exts. I have a lot of customization in my exts and my theme. What would be the best way to move ahead?
Also I have a NFS file server and SOLR search server configured with my current deployment. Need suggestions on that too.
I've heard recently, that the Migration Tool (6.1 to 6.2) now also supports themes. It won't be pixel perfect though. Check what it can do for you.
There have been some APIs that changed. Contrary to the comments given to your question, I'd say "It depends": I don't know how much of Liferay's API you use or if you just add functionality on top. You'll have to find out for yourself. The migration tool might help you.
The things that have changed the most are: Themes (using Bootstrap, as of 6.2) and Document Library (now including ImageGallery, which was still available in 6.0). Migration of data should be smooth if you follow the documented upgrade path. Migration of your portlets and plugins will definitely require recompile (within the new plugins sdk or updated maven dependencies) and probably adaptation to some changed API calls. I've seen instances where this was simple, but I've also seen hard cases.
As there have been no more updates for 6.0 CE for quite a while, I'm recommending to upgrade though (other than #FeinesFabi in the comment). If you want to have a long-term stable platform that you don't need to maintain for yourself, EE would be the way to go (supported for ~7 years after release)
For ext changes, you'll have to be aware that there are no guarantees: Ext allows you to change the inner implementation of Liferay, and that's what nobody strives to keep stable, even in minor updates. If you're using ext, you'll always have to be aware of incompatible changes. Ext allows you to keep your changes out of the official sourcecode - so they're well isolated. It doesn't say anything about the underlying implementation to be stable. With great power (ext) comes great responsibility. Keep your ext as small as possible - whatever you can do outside of ext should be done outside and use the public API.
The basic upgrade path (for Liferay itself, not your plugins) is quite well documented in the User's Guide.
We have an app written in Objective C. It uses CoreData, RestKit, about 10 viewcontrollers.
We would like to migrate it to Xamarin (so we can target Android and Windows).
I was hoping there was a way to bind the current code to a Xamarin solution and kind of rewrite features step by step within Xamarin (eg: replacing a viewcontroller at a time, and at the end replacing RestKit+CoreData, by SQLite + ServiceStack).
I am aware of the binding to Objective C option that they provide, however, it doesn't look to be the appropriate fit for this (way too complex, probably easier to rewrite the app from scratch).
Is there a way to migrate our current project to Xamarin so we can convert? or do we start from scratch?
Thanks.
Options:
Migrate full project - no;
Automatically create binding for libraries, rewrite business-code, UI-code - yes;
Rewrite from scratch using .Net/Mono classes - yes.
If code size is relatively small, you should rewrite the whole app. Moreover, thus you could have a chance to separate business-logic from UI code and tools libraries (RestKit, CoreData). In perspective, that code will be more reliable and cross-platformish.
This tool can help. It does Obj-c to C# translation (some manual cleanup required):
Automagical
Quite probably, a re-write, from scratch. One thing to keep in mind, if your back-end is .net.. and you are using DTO's.. like with AutoMapper from Entity Framework objects.. you'll be able to re-use those DTO objects on your mobile side with Xamarin. If you are using OData, I'm not sure if this is still a problem, but Xamarin studio wasn't generating OData service clients. So you had to generate them in Visual Studio, then take the generated client code and throw them into your Mobile projects.
sqllite-net is awesome. I've never had any problems with it.
https://github.com/praeclarum/sqlite-net
I currently have a project, with DTO Objects from an Azure WCF service, that I push directly down into SQLLite objects on IOS and Android with Xamarin. I use RestSharp, rather than Service Stack. I should probably go learn the difference.
If you are looking to use SQLCipher from the Component store, to encrypt your sqllite db locally on your device (Good advice to do so), you should be aware that there is an issue in android.. going to 2.2 or 2.3 with SQLCipher. Works for ICS and above though, if I remember right.
Just be careful on your security implementation for allowing clients to connect. I want to say.. don't take too much advice.. and don't take too little either. : )
VS2010 .Net4
Is SubSonic still the tool of choice? Are there easier ways to accomplish the creation of a DAL with the stock tools in VS2010?
I need to convert a project that was done with Subsonic 2.03 several years ago and would like to hear opinions on the "right" way to do this.
TIA
J
SubSonic is a fine ORM, but it lacks many features that Entity Framework 4 and NHibernate have. SubSonic also isn't moving forward as quickly as EF and NH.
It is possible that SubSonic will be the best .NET ORM two years from now, but that seems highly unlikely at present.
There is no one "right" or "correct" answer when choosing a .NET ORM. NHibernate seems like the safest choice right now, while Entity Framework 4 is a good fit for companies that prefer solutions from Microsoft. SubSonic 2 & 3 will work just fine in many situations and it may be better for your project to just maintain what is already working.
If u stick on MS SQL database, i can said Subsonic is fine and easy to code. But if u need other non MS database, my suggestion is nHibernate. I just switch back to nHibernate from Subsonic.
Is it possible to use Subsonic with VistaDB? I see it as a supported database for Subsonic 3 on the project website, But can't find a T4 template for it?
Will I need to use SR or I can use AR?
Vikas
Although the underlying architecture of SubSonic (System.Data.Common) supports VistaDB there aren't currently any templates for it. So although in theory it's supported it won't be supported in practice until someone creates those templates.
I wrote a vistadb provider for subsonic 2.x that was never made part of the official project. The main reason it's not in subsonic is that it's not freely available, the required dll for it is very encumbered with licensing. So no one wanted the hassle. You could take this provider code and use it to prepare a template, or just copy the sql server template, and make the required edits for reading the schema. I don't think that vistadb will ever be an official part of subsonic 3 since the vistadb dll is not freely available even for testing. I dropped vistadb because of performance issues.