So Have GetOrgChart sold to Balkan Graph as OrgChartjs?
Looks like it but the two products are incompatible.
Would be nice for someone in either of these two companies to explain the full situation so that customers can make informed decisions.
The product support from GetOrgChart was not really very good (notice how many questions here got an answer!)
The Enterprise version is not a cheap product and the documentation and information provided is sparse to say the least.
Also, valued features in GetOrgChart (Like MIXED_HIERACHY) seem to be completely missing from the Balkan Orgchart.js and the leaf structure has somewhat changed.
Come on team.... how about some details... what, why, when, how... has changed and how can we best accomodate. Also, is GetOrgChart now going to be phased out and or discontinued altogether? What is the roadmap?
Any insight here might help me know if I have wasted my money.
Regards,
Mark
BALKANGraph developer evangelist here
GetOrgChart is 10 years old product and has many clients using it, implementing new features is a risk, so we created new product called OrgChart JS with most requested features, like PDF export, grouping, assistant support, lazy loading for better performance, etc.
OrgChart JS is a new product developed by the same company. It has completely different API so migrating from GetOrgChart to BALKANGraph will require development effort
All new features will be implemented only in OrgChart JS
If you are working on a new project my suggestion is to use OrgChart JS, if you are existing customer still you can use GetOrgChart
MIXED_HIERACHY is working well now in the latest version of OrgChart JS
Related
I'm looking for advice from expert developers here on launching a service MVP. I'm currently in the process of finding an outsourced development team on Upwork and Fiverr, but there are differing opinions on the development approach, so it's hard to make a decision.
We're planning to launch an activity gift marketplace similar to https://www.tinggly.com/. It's a bit different from a typical multi-vendor marketplace, as the gift giver purchases a package that includes various activities, and the recipient selects one of the included activities.
There's a split in opinion among vendors between customizing a Shopify multi-vendor marketplace app and building everything from scratch. If you were in my position, which approach do you think would be best?
It doesn't need to be perfect because it's our MVP, but it's difficult to decide which approach would suit us the best. We aim to launch our MVP within 2-3 weeks, and the budget is 3.5k.
We've also included a link to our Figma page, in case that's helpful!
https://www.figma.com/file/mPWLU5enyyL14dMUDU6Ad9/Gifty-MVP?node-id=0%3A1&t=19xcdiN2h71YPqje-1
We were thinking of using multi-vendor marketplace app on Shopify. But because our marketplace only sell bundle packages, and the final product is not decided until the recipient chooses it, we would need a workaround if we insist on using shopify.
Okay, so this is a pretty generic and vague question, so please let me elaborate.
We have a large codebase which we are splitting up the past years to more individual self-contained libraries.
One of the larger and more unwieldy parts is our Word export module. It uses docx4j currently, however we run into memory issues with large exports with a lot of pictures. Besides that, it is pretty difficult to update the exporter due to changes in our domain model.
It has been a while since someone worked on it (like years...) so I took it upon myself to investigate the state of generating Word documents in 2021. I hoped a lot had changed, but some Google searches let me to posts of 2010, and libraries of 2012. Of course, it can be the case that a library of 2012 means it is just that good.
I have identified the following solutions, though I am probably missing a lot:
Docx4j (JVM), still maintained, we run into memory problems with that.
Docx4j with Content Control Data Binding. Seems to be some way to use templating?
Apache POI (JVM), have some okay experience with the Excel part, no experience with the Word part. The 'consensus' online appears to be that Docx4j is more user-friendly.
JasperReports. Don't know anything about that.
DocX, .NET library, no experience.
Office Add-In using Office.js (JS). Official API from Microsoft. Runs at client in Word, so required connection to an API.
docxtemplates (Node / Browser). No experience. Looks complete, don't know about performance though.
officegen (Node). Last release 2019.
Carbone (node). https://github.com/Ideolys/carbone. No experience also.
probably more...
So, as expected a lot of libraries in JS popping up as well.
Looking at my requirements:
using a template would be nice
running it as a service would be nice
efficient (memory wise, don't mind if it takes some time to generate)
We have quite a good JSON API available, which is very easy to maintain and maps pretty good to our domain model. My preference would be to use that as a source of course.
what are peoples experiences and/or am I missing some very good libraries out there?
I am new to hapi and for the last few days I've been trying out different project structures in order to keep the concerns separated and the codebase somewhat maintainable while not deviating too much from the "hapi" way of doing things. You can take a look at the folder structure here.
My project consists of a simple RESTful API, so I don't need to worry about views, rendering and so on. What I've ended up doing, and I'm not sure (yet) if this is idiotic or not, is to have the whole API logic (route handling, authorization, db access, etc) registered as a plugin. What this allows me to do is:
easily prefix all the routes with "/api/vX/" for a particular API version
easily swap API versions by registering all the dependencies (basically other plugins) for a particular API version in the plugin itself; this is what I meant in the title by "nested plugins"
I was hoping I could get some insight from other people using hapi and maybe see what what they are using, what's working for them and what's not.
Also, is nesting plugins "hapi"? I've taken a peak at the repos for a few of the popular hapi plugins that are out there and I haven't seen people doing it. Thanks!
A client wants us to develop a Picture Library system for them. The requirements are pretty typical - need to add pictures, tag them with metadata, store different sized versions and so on.
The client is keen on it being developed as a component which plugs into their existing SharePoint system. However, my feeling is that we would be better served building a standalone app - that way we don't have to shoehorn it into a SharePoint page and muck about integrating with SharePoint's APIs.
I am trying to look at this objectively and would welcome any arguments either way that people have.
Using an existing framework like Sharepoint imposes a lot of constraints on the design which makes the software architecture more uniform.
It does require some work on the part of the developer, because the developer does have to understand the API architecture and API's, etc.
However, developing a standalone application is the way that business's software architecture becomes a mix of 200 applications, using 20 different languages/architectures/platforms, half of which were developed by people no longer there - in short, a mess.
Sharepoint is documented, and will be supported probably long after you leave the company. Can you guarantee support for the application that you develop for as long as Microsoft will support Sharepoint?
You should do a cost/benefit analysis of integrating with SharePoint. You have listed some cons for integrating with SharePoint. Here are some pros.
Widely adopted platform.
Existing functionality to store/retreive/update images to data store.
Existing functionality to tag images.
Existing functionality to group several images together and treat as one virtual document (if using SharePoint 2010).
Keep in mind that you can integrate any custom ASP.NET page/application in Sharepoint so you can approach development like a standalone app. Your client wishes might include synchronization with Sharepoint's own picture library functionality and in that case you'll have to work with it's API.
It seems with SharePoint you are already done because it can more or less do what you describe already. What requirements do you have that cannot be met by OOB SharePoint?
I've used picture libraries for something similar before. While they have their quirks you do get a lot 'for free' like a UI, bulk uploading, metadata and 2 alternate sizes rendered.. My biggest gripe is they don't support the datagrid view so I cannot edit list metadata en masse like you can with other list types.
I am a junior developer and I have just graduated from university this year. I am working private with some people and I have just been given a music website to develop using DotNetNuke. I have a some experience using DotNetNuke which I have gained making small modules that take care of certain functionality on a webpages but I have never taken on a whole website before. I would love it if some one would give me some guidence on how to approach this project and answer some of my questions.
What are the steps involved in developing a dotnetnuke website?
How different is it from a developers perspective to develop a dotnetnuke cms website from a cms website which was developed from scratch?
When it comes to the database do you add tables to the database incrementally as you develop new functionality or do you plan everything in advance and create tables and stored procedures at once?
What are the steps involved in developing a dotnetnuke website?
Pick your version (if you're starting now, pick 5.1.1)
Installation (use Source package locally, Install package everywhere else)
Settings Configuration (performance, security, user info, etc.)
Adding & configuring core/third party modules
Adding & configuring third party skins
Custom Extension (typically module or provider) Development
Custom Skin Development
How different is it from a developers
perspective to develop a dotnetnuke
cms website from a cms website which
was developed from scratch?
Very. When you're starting with an established CMS you're inheriting solutions to tons and tons of solved problems. In the case of DNN, you have a substantial framework at your disposal. The focus will be more on learning and leveraging the existing API/features. If you're starting from scratch you're providing that foundation yourself. Using an established CMS is not necessarily better than the other - it depends on what you're trying to accomplish. If you require fine-grained control over everything and you want a great learning experience, rolling your own may be the best way to go.
When it comes to the database do you
add tables to the database
incrementally as you develop new
functionality or do you plan
everything in advance and create
tables and stored procedures at once?
No matter what your project is, I'd suggest doing things as they are needed and not before. I think "doing everything in advance" would be impossible/horrible anyway. The heart of this question is really going to be defining your development process - I don't think this would necessarily be any different than in other projects. I like to define the features I want, organize them based on their relation to each other (which should come first due to dependencies, etc) and start implementing them one at a time and give each one the attention it needs.
You may also want to look into Lee Sykes' tutorials on module development using OpenWebStudio. However, I'm more on the design end, mainly just skinning, configuring, SE optimizing sites and matching client needs to our library of licensed 3rd party modules. However, the DNN community is VERY supportive and VERY helpful. There are some great resources out there, and I've found several blogs by the core development team to be essential for helping me wrap my head around the DNN framework.
Keep with it, and don't be scared to ask questions.
References:
www.dnncreative.com - Lee Sykes' Site, many tutorials on the how-tos of the DNN system. It's well worth the yearly subscription IMHO.
www.dotnetnuke.com - The main site for the DNN community
www.snowcovered.com - Central (AFAIK) site where many module developers sell their products, everything from skins to modules.