I'm developing a portlet application on Websphere and its a real nuisance whenever I make modifications to the design (xhtml page) all the html components (plus setters and getters) are auto generated in the Java bean file.
I only need 3 or 4 variables that I directly map from the bean to the web page. All the extra generated code and imports are just inefficient. It's also a waste of time to keep going back and forth and re-erase all the auto generated code. Is there a way to disable this feature?
Related
I'm rewriting some templates and functionality previously developed using AngularJS 1.x which are currently managed and developed as static assets in an ASP.NET MVC application and are used alongside razor syntax (.cshtml). There are no components either. Imagine the AngularJS modules as a huge bunch of jQuery code linked and coupled with views.
This time, I'm implementing everything we need in a Vue 3 app in a separate git repository and I'm also using Vuex 4.
I'm hoping to be able to do the following:
Build the Vue app
Load the assets in BundleConfig.cs
Link the assets to my _layout.cshtml to have them on all my pages.
Use the components wherever I need them.
I'm going well on developing the components and functionalities within its standalone project, yet I'm facing several problems and/or ambiguities.
I have pages that are mostly if not entirely rendered by the client-side. These pages may or may not be handled by a client-side router such as vue-router.
I also have pages that are mostly rendered by the server and then stuff is added or dynamic contents are loaded by the client-side. These pages can't use a client-side router.
I'm not using a router and I'm having a hard time developing and testing those pages that are mostly rendered by Vue.
if I use a router I think I won't be able to do what I'm planning to do about those pages that are mostly rendered by the server. I really need all pages (whichever kind they are) to have access to my Vuex store.
What do you recommend I do to make it easier for myself both in development and production?
Should I create several static HTML files for each of my pages in Vue's public directory tweak Webpack's configuration in order to simulate what will happen in production (use within the ASP.NET project)?
Should I start having a router, put all pages that are mostly CSR under its control, and somehow configure it to have nothing to do with my other pages that are mostly SSR?
I need to be able to debug and test stuff when I run npm run serve and then do what I'm tasked to do. Unless the whole plan is a bad/wrong idea somehow.
I might also be able to build my Vue app as a library and then, in the ASP.NET project, init a small Vue app that imports that library and that itself is bundled with the back-end project. The whole reason I'm doing this is to make the client-side stuff reusable and easy to maintain. I don't want to take a GET SHIT DONE approach.
Thanks
I am building a basic Angular2 + Polymer seed application (as well as rebuilding personal site), when testing it out on mobile I ran into a few problems. I am using the Router supplied by angular2/router and have inserted a <script src="webcomponents.js_here"></script> to include webcomponents.js after angular 2.0.0-beta.7 (as I write) has been pulled in.
Simplest example I could boil it down to is reproducing the error in the Angular2 Hero tutorial. If you check this plnkr out on a mobile browser you will see that when you navigate from one view, to another and you try to go back to the previous view relying on window.history.back() as the ng2 tutorial does, you will be able to go back to the previous views but at the following costs:
The view is not loaded properly
constructor() gets called but ngInit() never gets called
If you move the service-fetching logic from ngInit() to the constructor (as I did in the plunk) to test to see if the service data is still being fetched properly, the view is still not rendered properly (makes me think there is some polyfill conflict issue stopping the structural directives (*ngFor in this case) from working and manipulating the DOM properly. To get the view to load properly and the structural directives to work again with the service fetched data, you have to navigate to that view in any other way but using the window.history. This makes natural Back/Forward button routing an issue in Angular2 apps that use Polymer. It seems that as of posting this it only happens on mobile browsers.
I am testing on an iPhone 6 plus iOS 9 (9.2) and Chrome version 48.0.2564.104
Could this be some sort of view caching or polyfill problem?
I need to redirect with some parameter from JSR286(IBM) portlet to JSF 2.0 portlet.
I am having the page unique id and friendly url too.
I have tried response.sendRedirect() and requestDispatcher.forward() but no success till now.
Please provide me some solution.
For navigating between portlets you should not simply forward or redirect pages, since this is not the way to go. The proper way to communicate between portlets, even on different pages is to use interportlet-communication (IPC), commonly known as portlet wiring.
But it all depends on what you mean with a "JSR286(IBM) portlet". A portlet is either a JSR-286 portlet following the global specs (which are the same for all vendors, IBM, Apache, Oracle, Liferay, ...) or you have a portlet using the IBM API/iWidgets, in the last case, portlet wiring is not possible if I remember correctly from the docs.
Anyways, JSF or not, a JSF 2.0 portlet remains a JSR-286 portlet, so you can use normal events in this case as well, though I'm not experienced in JSF. Both portlets should have a portlet descriptor, in which you can declare:
The event, using <event-definition>. Please note that when your JSF-portlet is in a separate portlet application (in a different portlet.xml file), you will have to use an XName, not a normal name.
The events a specific portlet can publish, using <supported-publishing-event> (your JSR-286 portlet)
The events a specific portlet can subscribe to, using <supported-processing-event> (your JSF 2.0 portlet)
Afterwards, you can send an event in your JSR-286 portlet from within the ACTION phase, by using the ActionResponse.setEvent() method.
From the JSF 2.0 portlet, you should still be able to get the PortletRequest/PortletResponse from the context. If you check if it is an instance of EventRequest, you can retrieve the parameter using EventRequest.getEvent(), allowing you to pass parameters between portlets.
If your portlets are on separate pages, you'll have to got the Administration of WebSphere Portal (I assume you're running that since you're talking about IBM), and define global targets for the pages so that events can be triggered cross-page (otherwise wiring is only available for portlets within the same page).
We are trying use Orbeon Form runner with server-side embedding.
The form renders properly on form runner, however in our java web application the form is not rendered properly i.e. CSS issues.
All the /orbeon/* resources are retrieved from orbeon application, but the CSS is not applied properly. I suspect it could be because of the extra div that are added for the embedded/portlet.
In Form Runner
Full Size Image
In Java Web Application
Full Size Image
Also, if we use the wizard view, it works in form runner, but does not work in embedded java web application. The sections are shown on the same screen.
When Orbeon Forms produces the whole page, it adds an orbeon class on the body, and then pretty much all the CSS that comes with Orbeon Forms is "prefixed" with .orbeon …. This is done to minimize the risk of Orbeon Forms' CSS conflicting with your own CSS.
I can't be sure that this is the problem, but if the CSS doesn't apply when embedding, you might need to add a class="orbeon" on the element that contains the content you're embedding.
Thanks for your guidance. I was able to resolve the problem.
When embedding forms, as you said orbeon regenerates the CSS, and also appends "o0" (#o0xforms-form) to each control's id. However, the xforms.css still refers to control with (id #xforms-form), hence styles are not applied correctly.
Overwritten the xforms.css with custom app-xforms.css which uses (#o0xforms-form) which fixes the problem.
Are there any recommendations for a design surface (or design tool) that could be used by a designer (the dude/dudette with the black turtleneck) in the process of building an ASP.Net MVC application?
Such that once there is agreement on the structure of the Model, and the interactions required by the app, then the designer goes away and builds out the UI (V in MVC) using this design tool, while the developer goes away and builds out the code (M&C in MVC) using Visual Studio.
As I understand it now, this designer person would also need to use Visual Studio and build the Views using Razor (or other view engine) syntax, instead of having the ability to build the Views using a design surface with drag-drop layout and property settings and the like.
I think you could ask them to give you a harcoded HTML for each view... then, you replace the harcoded data once you place it in Razor.
That is the beauty of Razor... it is very easy to pass from fixed HTML to a razor view.
Razor requires programming, and creating views is not an arbitrary task. I'd let the designer work in whatever program they like where they can excel about design and let the programmers worry about how best to create the views and programming in Razor (which is really just C#/VB with some extra syntax).
It depends.. what kind of skills does your designer have? Are they a true designer (no JS/jQuery/etc knowledge.. they live & breath PSDs) or are they a designer/front end engineer (they know js/jQuery, the diff. between IE7 and IE9 from a rendering pov).
If you've got a true designer then the best thing to get would be HTML. A PSD would be okay as well but if they can convert their design into HTML they've done a lot of the hard work for you (unless you love figuring out floats and margins and all that jazz). That said if you're using something like Twitter Bootstrap or Blueprint CSS then they would obviously have to know how to use that as well.
If you're lucky enough to have a designer/front end engineer then it's well worth your time to teach them some basic razor synax like #Url.Action and #Html.BeginForm. They can tell you the actions they need and you can work together by giving them a fake data/response version first which they can use while you create a real version. And in this case they can either use Visual Studio OR you can set it up so that they have your site hosted via IIS on their machine and they just use your source control to get latest which automatically gets placed in the right directory. Then they can just continue working in whatever editor they prefer as they should only be working in html which will get updated live. That said if you're using ASP.Net MVC 4 bundling you'll have to decide how to maintain bundles.