When you start a new project (whether it's personal or professional) what do you have at hand to quickly start developing the project?
For example, when I start a new project at work, I have the following already setup from a custom sandbox:
Two different authentication classes, LDAP and CAS which I can change via app.yml
Custom form widgets which I use across most applications
Capistrano deployment script for deploying the project to staging or production servers.
A mail template class which uses an XML file for the templates to send emails
Mail server, ldap etc. settings all configured.
Bunch of icons and the same CSS (which with some exceptions is always the same for each project)
custom error pages, layouts, login layout etc.
static pages such as about, contact us etc.
Useful plugins such as sfFormExtraPlugin, twig etc.
jquery and jQuery UI libraries
Basic local ACL and translation model classes and some other default models.
Tasks - send email task and build translations.
custom tools class for doing some custom stuff
custom factories and some default routes
helpers which I will most probably use are enabled by default (i18n, partial etc.)
And some other things :-)
I'm just wondering what you do to make your development quicker and more efficient when starting a new project. Hopefully I'll learn some new things from what you do.
Thanks folks!
Great question and great list. Here's some more:
As a general practice, whenever we develop a feature that could be used across projects, we develop it as a plugin so it can be easily dropped into other projects.
Custom form formatter that uses our own widget/validators in place of the default Symfony ones.
Custom mailer with support for sending processing templates as emails and better HTML email support.
Plugin for minimizing/combining CSS and JS assets.
Symlink from web/sf to lib/vendor/symfony/data/web. Better than an alias in apache.
Custom admin generator templates.
Quick setup script that takes commandline options or read a config file to create full local dev env (init the project, setup a vhost, modify etc/hosts, import to svn, create svn externals for Symfony and key plugins like sfDoctrineGuard)
Custom Project skeleton
Custom Javascript helper based on Apostrophes new a_js_*() helper functions
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
As far as I understand that, there are two major options for Vue and .NET Core integration within single MVC/Razor project.
Option 1.
MVC/Razor-rendered non-reactive page is used for authentication with built-in ASP.NET Identity. Vue is not involved for authentication/authorization at all. As soon as users are authenticated, they are redirected to another MVC/Razor page that is used as a HTML template for Vue. It’s possible to combine MVC/Razor rendering and Vue. For example, user name on the top of the page can be rendered by MVC but button actions and data tables will be further processed by Vue. It’s possible to use many pages (so it will be MPA, not SPA), it comes naturally. Using *.vue files is not possible. MVC routing seems to be primary routing option (not sure, would be possible to combine with Vue routing and whether any needs for that). Vue JS files can reside anywhere in the project, for example, can be bound to the HTML pages similarly as CS files in Razor pages do (and it’s nice). Then, all these JS files along with Vue itself can be bundled to the wwwroot by Webpack. Vue CLI is not available but seems there is no need for that.
Option 2.
MVC/Razor is not used for rendering user pages at all. Authentication occurs by third-party solutions like IdentityServer and with Vue-managed pages. .NET Core is used exclusively as a WebAPI for Vue and to hold a project. Vue part is totally independent from the MVC/Razor part, they even render pages to the different HTTP ports so proxy is needed to convert Vue HTTP port to the MVC/Razor HTTP port to make Vue works in the single project. We can use either Microsoft.AspNetCore.SpaServices.Extensions or NuGet third-party VueCliMiddleware for that. All Vue files typically reside within a ClientApp folder and then are building to the wwwroot folder. Using *.vue files is possible. Vue CLI is available and recommended to scaffold new application to the ClientApp folder (but further CLI seems is not needed). Vue router seems to be the only option for routing. SPA seems to be the primary choice as a structure (not sure, whether MPA is readily available option). Webpack is still used for building Vue app from the ClientApp to the wwwroot.
I started mu Vue journey with Option 1 even without webpack and npm, just with CDN tag on the one of the Razor pages and it works very well. For me Option 1 seems less complex while more flexible. My primary concern is that Microsoft uses Option 2 as a built-in templates for Angular and React in Visual Studio, so I probably is missing something and soon I will be pushed to rewrite my app to the Option 2.
What you guys think which option is better and whether my understanding explained above, is correct?
I have a rest-api app I am working on. I run generate-controller on my domain, and a controller is generated, but in other profiles I have been able to "install" the templates that were used and customize them. This profile has no install templates command.
All attempts at doing this with the rest-api profile have been unsuccessful. I exported the templates that are used from the plugin jar and placed them in the file system, in a place grails could find them, but they are not used.
Should it be possible with this profile to customize the templates used for code generation - controller,service, view GSON? If so what does that project setup look like? I am working with a vanilla 4.0.0 rest-api profile project.
Section 10.5.3 in the documentation glosses over this, and contains a dead link to the scaffolding plugin, so it is of no help.
I tried to add the scaffolding plugin to my project build.gradle.
compile "org.grails.plugins:scaffolding"
but then the project won't even run.
org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'abstractViewResolver' available
It seems like it ought to be possible to customize the code generation templates in the rest-api profile, but I can't find a working configuration/setup to do it. Any pointers would be greatly appreciated.
When I generate the scaffolding after adding the scaffolding plugin, and run install-templates, it installs the templates for a web profile, rather than rest-api, so they are of little use. And even after doing so, they are not used in generation.
Should it be possible with this profile to customize the templates
used for code generation - controller,service, view gsps?
It probably should be but I don't think the templates are currently supported in the rest-api profile. I don't think install-templates even exists in that profile by default. You mention GSPs but I would not anticipate that install-templates would generate GSP templates in a rest-api app because by default, there is no GSP support in the rest-api profile.
If so what does that project setup look like?
If support is added for this I would expect the project setup to looks just like a typical rest-api app plus the templates installed below the src folder.
Feel free to submit feature requests at https://github.com/grails-profiles/rest-api/issues and/or pull requests at https://github.com/grails-profiles/rest-api/pulls.
I have an existing grails app with multiple forms. I need a CMS which allows me to add existing grails forms to this cms and assign each form different permissions. I need to be able to change site template css from admin page. Something like dotnet nuke where you can add existing asp.net page and assign permissions to this page and add custom theme.
Features requested:
Integration with Active Directory
Integration with MS Exchange
Set up grails form security policy from protal admin ui
change form css theme from portal admin ui
easy integration with portal
I'm not sure exactly what features it supports, but Weceem is a CMS implemented as a Grails plugin, so that's an obvious starting point.
There is Maglev plugin for Magnolia that you can use, but AFAIK it works only with 4.5.x branch, not with the latest version.
Other then that, if your main requirements are security and being able to pull the theme from CMS, you can deploy Magnolia and your grails app in same web app, configure Magnolia to handle all incoming requests (that's by default) and only configure bypass inside of Magnolia for cms subchain for url where your form is available. This way Magnolia will take care of the URL check the security, make context available for you and you can refer from your form to the theme that is selected by editors in your Magnolia installation. While this description sounds probably a bit convoluted, it's actually very simple to do.
HTH, Jan
I'm writing a Grails app which I'd like 3rd parties to augment at runtime. Ideally they would be able to add a JAR/WAR to the webapp directory which contains new domain, controller and service classes, new views, and other content.
Is there a simple way to do this within grails? Would it be simplest to create a startup script which copies the new classes etc. into the relevant directories and then updates grails.xml and web.xml?
You will be able to do this in version 2 of grails in which plugins will be also OSGI plugins http://jira.codehaus.org/browse/GRAILS/fixforversion/15421
It seems that the Grails plugins will actually fit quite well for this: http://www.grails.org/Understanding+Plugins
A plugin can do just about anything... One thing a plugin cannot do though is modify the web-app/WEB-INF/web.xml or web-app/WEB-INF/applicationContext.xml files. A plugin can participate in web.xml generation, but not modify the file or provide a replacement. A plugin can NEVER change the applicationContext.xml file, but can provide runtime bean definitions