In one of our projects we have reached the point where we have to ditch out old Madisson-based platform and move on. Unfortunately, Aurora does not look like a perfect fit, so we are looking at alternatives.
One option is to build a GWT based front end. This would allow us to drop JSP, Dojo and most JavaScript in favor of a Java-based platform.
Has anybody tried anything like this before?
How would I make it work with for example Dynacache?
I would read this redbook. It has an example of how to code the JSPs - http://www.redbooks.ibm.com/redbooks/pdfs/sg247393.pdf.
Also if you're moving to FEP6, you'll also want to use the WebSphere Commerce tag libraries and some of the metatags so that the inline editing and some of the advanced store preview features work correctly.
Finally, I would engage your local IBM technical team since there are other customer who have done this before and you want to learn from their best practices.
I've no experience with IBM starter stores. I'll try to help, though.
The back-end/front-end integration occurs by putting RPC servlets in a package shared by your back-end and front-end code, as explained here. It shouldn't be a problem to set that up.
I've no idea if dynamic caching will still work, but those RPC calls are also based on URL and I don't see why the cache wouldn't work for them if you set that up properly.
If you don't want to rewrite all your client from scratch and for a step-by-step migration, you could keep your JSP and use little GWT modules to replace the Dojo/js code on your pages.
In the same way your old Dojo/js code can be called from the GWT module if you would like to keep some parts of it.
Hope it helps...
I am not gonna ask you why you want to drop Madison starter store JSPs/DOJO apis and javascript, But that will be massive amount of work for you !
I guess you need to architect your calling from GWT to Server side to be like RESTfull format and can take parameters and add the dynacache entries like servlet/Rest paths that way you can cache the responses from back end which can be JSON or XML format . and of-course that will work
e.g:
<cache-entry>
<class>servlet</class>
<name>/path/GetCatalogs</name>
<property
name="save-attributes">false</property>
<property name="store-cookies">false</property>
<timeout>3600</timeout>
<priority>3</priority>
<cache-id>
<component id="storeId" type="parameter">
<required>true</required>
</component>
<component id="catalogId" type="parameter">
<required>true</required>
</component>
</cache-id>
...
</cache-entry>
Related
I found this free PWA https://www.the-qrcode-generator.com and now wonder how I could do one such myself.
Since I couldn't find any access to its source code I wondered if it'd be difficult to reverse engineer.
I'm interested in building a PWA with QRCode functionality.
This one was created with AngularJS v1.3.20. You can find the source in your console windows under Sources tab. You can easily beautify the code inside the window to make it readable.
If you want to know how they organized their rest API, the browser network tab will help a lot, just filter by XHR and examine all the call from the front end to be.
The front end is very hard to revers engineer, because most sites are served as minified bundles, so you can't see the original code.
You can however find some other information about what they used to build it, for example in the html source you can see some ng-* tags, which indicates that this is angular, you can also see that body has attribute data-ng-app meaning this is angularjs and so on.
For the QR logic you can see that there are no back end calls, meaning that it is written entirely in the client. I would search for already available solutions for that.
The idea is not new, like Wordpress, Oxwall : a platform created by some guru guy that allowing other dev guys to add new apps (like forum, blog, market-place, whatever) into the platform easily. By easy, we mean either just install new plugin by upload or less user friendly coding new plugin without changing the core code.
Actually, we have a working solution with angular1 but quite clumsy, that's it, multiple stand-alone ng-app within a website, like:
domain.com/forum-spa
domain.com/dating-app-spa
..etc..
Good thing about it is quite straightforward to implement, not much to worry about lazy-loading. But we are not happy with that approach for many reasons.
Angular2 is really close. We hope it can bring a better solution for building a large web platform
iframe
custom components that are added at build time that are added depending on user data like explained in Angular 2 dynamic tabs with user-click chosen components
This approach is compatible with the offline template compiler
There is also a more flexible way that supports user-provided component templates How to realize website with hundreds of pages in Angular2
This approach is not compatible with the offline template compiler and requires the Angular parser and compiler to be included in the build output.
I've been studying sapui5 framework for some time now and I always used javascript views in my applications.
The question is - are there reasons why should I prefer xml views over javascript, if I should do it at all? If there are some, what are they?
If I want to start trying to write xml views, what is the best place to learn the basic syntax and where can I find API reference for controls created using xml? The SAPUI5 API is written for use with javascript.
Thanks.
Major reason, in my view, is strict separation of concerns. XML views, by their nature, preclude code. Your XML view is therefore strictly presentation logic - a great outcome for professional enterprise development. It also reduces the significant lines of code to code out the ui and thus improves readability and maintenance of code.
the reason I use XML views is because this is the standard approach of the Fiori apps by SAP. It creates a situation where developers only have 1 approach. Also to me they are easier readable.
Generally speaking I see that in the mobile library the xml views are used while in desktop usage js is still leading. On SCN you can find many similar questions.
The library of examples can be found in the same API page under tab EXPLORED.
Perhaps using the webIDE (which offers a local) install can provide a really good base for you to start development using xml based views.
Where you say the API is written for js views, this is true because the controls are written in JavaScript. Look at it this way if you have a namespace in your xml like xmlns:l="sap.ui.layout" any xml element prepended with l like <l:GridData ...
becomes a call to sap.ui.layout.GridData and if you look at the api for this control you can see what attributes you can add to this control / element.
Also if you have xmlns="sap.m" in your namespace block then anything like <Page /> <Table /> become sap.m.Page or sap.m.Table so the api is still a valuable resource and the explored section is great to see controls in action.
Hopefully someone can help me, I'm new to EPiServer and have been given a data migration task. We are using the latest version 8.5. I need to migrate content from a clients home grown CMS (that luckily is in a tree like structure) to EPiServer. There doesn't seem to be a whole lot of information about this on the web - perhaps I just don't know the right thing to search for.
It looks like using the EPiServer.ServiceApi might be the route to go but again locating useful documentation is proving difficult.
I was thinking of setting up the client CMS in SQL Server and writing a simple console application to call the EPiServer.ServiceApi inserting the content. If anyone has any information on this or better still and example i would be very grateful.
Thanks,
Dan
If you are just importing content from another CMS I would write a scheduled job in EPiServer:
http://world.episerver.com/code/dannymurphy/Stoppable-Scheduled-Job-with-feedback/
That job then uses the standard IContentRepository to create content:
http://world.episerver.com/documentation/Items/Developers-Guide/EPiServer-CMS/8/Content/Persisting-IContent-instances/
That way you can run it whenever you want and have access to EPiServers complete API. Also you can see progress of the import through the job status.
In the job you can read the content as a file in any format you like or directly from the source CMS database or some xml or RSS feed perhaps.
I have moved content from PHP, Java and .NET CMS this way. In .NET you could even access the source CMS via WCF or SOAP if available.
The ServiceApi is relatively new and more focused on Commerce products and media assets rather than CMS page and block content so I wouldn't use that.
There is complete documentation below for the ServiceApi by the way, did you not find it?
http://world.episerver.com/documentation/Items/EPiServer-Service-API/
Regarding language management you can read more in the below links:
http://cjsharp.com/blog/2013/04/11/working-with-localization-and-language-branches-in-episerver-7-mvc/
http://tedgustaf.com/blog/2010/5/create-a-new-page-language-branch-programmatically-in-episerver/
Basically you have two options for multiple languages. If the content is just straight translations you should create nine different language versions (branches) of the same page. You can also have multiple sites in an EPiServer installation but that requires 9 separate licenses (and the associated costs).
I've done a lot of EpiServer content migration projects. The easiest way if it's possible is to export your current sites tree in Json and then import that into EpiServer. I've had to do it on a recent project and mixed with Json.net it's pretty easy.
If you want to go that route you can find all the code to do it here: EpiServer Content Migration With Json.Net/
I have a plug-in that I am distributing via an Eclipse update site.
I want to track how many times it is being downloaded, and preferably by whom.
For regular pages on my site, I can use Google analytics. However, Eclipse doesn't use any HTMLs when going for update sites.
Is there any way to do this when I don't have access to the hosting apache?
A dirty trick you can do is to add a dummy feature in your site.xml which points at a counter page instead of a .jar file. E.g.
<feature url="http://yourcountersite.com/counterpage.php" id="" version="">
<category name="YourCategory"/>
</feature>
The update manager will contact the counter page when it tries to install stuff from your update site but will otherwise ignore this feature.
AFAICT, your only option is to work with web server logs. I wrote this article about tracking Update Site downloads using AWStats, but it requires some server side tweaking. This is just one time set up, though. After that, you use AWStats using its' web interface.
When you say update site - do you mean your own URL or an eclipse repository ?
I guess really you need access to the logs of the underlying server. This way you could monitor whatever type of request eclipse initiates (I'd guess its just a standard HTTP request)
Steve