I want to use kentico's polls module but I need to add a "tooltip field" and add some extra HTML. Is there a way to clone the module with the same functionality and let me to edit/add fields to the module classes.
I was trying to edit the module but it shows a message saying Classes cannot be created or deleted in installed modules.
Are you trying to modify the class in the module and it's giving that error? Or modify the module info itself?
Some module classes allow edits and additions. If this is not the case for the polling, you have two options.
1: clone or recreate the module and clone the web parts that use it to use your new module. This is the safest but longest task and may require some digging into Kentico drivers using a decompiler like just decompile to find any other code pieces you need to clone and modify.
2: open the database in SQL management studio, and edit the cms_class on that class and manually change the bool values that allow it to be edited. This comes with the risk that on future upgrades it may break it, but it's a small risk.
Related
I want to create a workflow automation where an activity comes in and user can setup a multilevel workflow.
For frontend i am using https://reactflow.dev
How to structure things in nodejs backend. Things like database, accessing control flow statements, statements which requires crons.
You also may want to have a look at node-red.
It's an open-source product that does exactly that.
There's a set of built-in nodes.
You can develop your own nodes, or import 3rd party ones. Which are stored in NPM.
You can also just create a node with javascript or typescript code in it, on the fly.
You should check Flumejs: https://flume.dev/
https://flume.dev/docs/quick-start/
Also you should see this code sandbox example. Try to read the code
and all the dependencies: https://codesandbox.io/s/node-based-code-generation-test-forked-ll9flz?file=/src/App.tsx
I hope you find this helpful.
I have made three different applications in j JHipster with monolithic. I need to merge these applications. I know that by using micro-services my quest can be easy but the current requirement is to do the merging with the monolithic pattern only.
I need to merge two applications with another or main application. I am using MySQL as database. I don't know where I need to change and how. Please help me out, I am a newbie in this scenario.
i tried to create a java file for setter getter methods and and a dao file for three databases and now in the main class file and am trying to take every dao file as an array of object and integrate it and put it into the third db.is it possible.i wanted to show the code bt,since i am new not able to maintain the coding standards to show.
by this i way i tried to involve three databases in a single scenario and want to complete my query through CRUD model.
as you already pointed out, the proper way of merging here would be using the microservice option, which you cannot take, as you are forced to use monolithic architecture...
almost automatic merge
if you did not changed anything to your code, after generating the entities, you just can put the contents of your applications .jhipster directory into one, and run yo jhipster --with-entities to regenerate the entities in one application. You should keep in mind, you will have to take a look at your main/resource/config/liquibase folder, to set the migration ids properly.
manual merge
For this you should be more experienced in the underlying technologies, as you will have to:
recreate your entity classes
recreate zour DAO/Repositories
(maybe) recreate your services, or service implementations
recreate your REST controllers
do a proper liquibase migration
provide some tests
migrate the frontend code, by adding states, components, templates etc..
the most of these things you just can copy paste already generated code.
For more information, you should ask more precise, what is not working, if you already tried something...
I want to be able to build 30+ packages in SSIS and be able to test/develop them in isolation. I also want to be able to run these from a Master/Parent package.
When it comes to delivering the SSIS parent package I want to be able to change the connection string once and have this trickle down to all child packages. Other developers will be building and testing without using the master package and want to be able to develop these in isolation.
I've seen many articles on XML config/parameter mappings etc. but I've not seen any definitive guide on how this should be done & what is best practice.
The project we have created also only allows packages to be linked in the solution as an external reference rather than as project links (is this the legacy format?). I'm wondering if this type of project could hamper the ability to achieve shared connection strings.
Answering this myself for reference. Basically there is no streamlined way of doing this in the Package Deployment model. It is much easier to achieve this using the Project Deployment model which is the default in VS2012. However, we don't have this luxury.
I had to create some parent variables contained in the master package. These are then set to the XML config. The child packages then have direct config links to the parent variables, with the target properties mapped to the connection string properties of the connection managers.
i'm newbie in JHipster and i'm trying to figure this, when i create a new entity JHipster generates several files, angular, html and java classes, now if i want a common code for all this generated code i must edit each time that i use the yeoman generator? what i want is:
Custom Index template, and pages, is secure to edit them?.
Customize the entity tables, entity forms using angular, maybe extending yeoman generators
Customize generate java classes, maybe i think using AOP
So i need to edit each time for each generated code? and is a good practice this or what i want? for clarify more i want to use a Custom Bootstrap/angular Dashboard template like Minovate, i see how to customize bootstrap in the documentation but not about what i'm asking for, Thanks.
JHipster is just a code generator, once generated the code is yours.
For angular screens I would say do as much as you can in CSS/SASS.
But it's very likely that you will need to build some screen mixing several entities and change the structure of entity screens.
So you should rather consider them as a starting point and do your own stuff in another folder so that it does not get overwritten by next re-generations.
This way you can still update your entity definitions in .jhipster folder and re-run yo jhispter:entity <entity name> on the entities you modified.
Customising java Entities is usually much simpler and you can easiliy achieve this by merging generated code with git and defining your service classes.
AOP seems overkill here.
Extending a yeoman generator is a lot of work.
I suggest to use some VSC (git, subversion or whatever you like) have a branch dedicated to plain jhipster generated code and another one where you make customization.
Eventually regenerate on jhipster branch and merge back on yours.
You should at least reduce manual intervention.
I'm new to Haskell and Snap and I want to write a simple bug-tracking application. I set up a Snap project using $ snap init and it works. The problem is that I don't know how to go any further.
I want to create a snaplet Tickets that uses a database to store bug reports, and use that snaplet in my main web application.
I read the documentation about snaplets but I couldn't figure out where to put their source code (in the /snaplets directory, I suppose? If so, how do I load them?). Could anybody point me in the right direction?
Are you sure you need to create a separate snaplet for Tickets? The snaplet infrasructure is meant for reusable components such as session management, authentication, database access, admin panels, user management, etc.
Are you going to be using your Tickets self-contained module across multiple web applications? If so, then by all means go ahead and create a snaplet.
In any case, it sounds to me like you are at least in part asking how to organize a project with multiple "modules" or "parts" while using snap. I'll try to address this below. Please let me know if you feel I have missed the mark.
Assuming you don't need to create a separate snaplet for Tickets:
For functionality specific to a single site, I think you would be better off creating a few modules and developing the code for the functionality right inside your current application's package and module hierarchy. Here are a few points on how I have been organizing my snap projects of late:
I put my database-related code under modules in MyApp.DB.
namespace. You could have a MyApp.DB.Tickets that contains all
database calls needed for operation on your Tickets module.
I put all UI-related functionality under MyApp.UI. namespace. You
could put a MyApp.UI.Tickets module that contains your Handlers,
your Splices, your Forms and so on.
To handle forms, I use the excellent digestive-functors library. You may find this blog post helpful if you don't know them already.
I usually have a shared UI helper library under MyApp.UI.Helpers where I place common code used across all/most UI modules.
I usually have a shared Form helper library under MyApp.UI.Forms
Any code tangential to the fact that my application exposes a Web UI goes outside the MyApp.UI. namespace. So if my application needs to perform some offline analyses, I may put them under the MyApp.Analysis. namespace.
Once you define and export your Handlers under MyApp.UI.Tickets, you can go to your Site.hs file and wire them into your application at specific routes.
For inspiration on how to handle database connections, you can check out the postgresql-simple snaplet.
However, if you do need to create a snaplet:
A snaplet is simply a stand-alone application that uses the Snap.Snaplet infrastructure, (typically) has its own .cabal file and (typically) is its own Haskell package. Snap then gives you a way to embed or nest this re-usable, self-contained application in yet another snap application. Think a hierarchy of Russian dolls.
Assuming you performed something similar to what I described in the section above, you are now 95% ready to convert to a snaplet. Just name your application snaplet-tickets, expose a SnapletInit using makeSnaplet and use nestSnaplet in another snap application to include this reusable piece of functionality right there.