Activities of "commondesk"

@leonkosak

@commondesk: It's not fair that you blame application framework for not knowing library or framework "inside" ABP/ANZ. Just accept reallity - modern full-stack web is noticeable more complex than native (desktop and other native) frameworks. There are so many libraries and frameworks and each of them have active development.

Google, does a fine job of documenting Angular. Microsoft documents ASPNET and C#. Telerik documents their proudcts.. Im happy to learn new framework, but you cant unless there is some documenation.

Modern full stack web frameworks are not more or less complicated that desktop ones. The problem is there written my many groups of people and therefore the documantion standard is lower.

Don't get me wrong, I like the platform and the product. My goal in posting this is to air out several architectural problems, and search for ways to manage these issues.

These are the problem i see

1 - New templates are made available, 6 in 2019 alone, and there is no documented way to upgrade your code to them. New templates serve two purposes, they provide new features and they fix bugs. Fixing bugs is a non-optional requirements while adding feature is completely optional.

While this is a problem for anyone who changes the source code of a large system, little to no thought has going into best practices for attempting to upgrade. We must find a way to merge bug fixes into later version.

In the past i made a suggestion that changes between each template be provided as a set of GIT patch/diff files. This way we could apply the diff's that represent bug fixes. I hope to hear more feedback about his approach

2 - Beyond adding fixing bugs and adding new ANZ template features, we as developers need to add our own change to the template. This is non-optional for us as we need mold ANZ to meet our business needs. In this thread, you will see that i made a proposal for how, ANZ could structure their system so changes could be made easyer to merge. Creating TypeScript base classes and empty Stub classes etc. I hope to hear more feedback on this approach.

3 - Source code for the system is provided, but there is little documentation for the source code. I know that asking developers for source code documenation is always a difficult subject. But for a comerical product its much more expected than for an open-source product. This is a commerical product with a $2500 a year renewal. Im not looking for source code telling me how each line works, but i would like to know many things includeing:

• Where each element of the user page is located. TopBarMenuCompnent is at the top of the screen. etc.
• How to make use of the baked in popup dialog system.  It turns out some of these are based on other library's, that have documentation.  Why not just provide a link to that documentation.
• How aspects of the system can be disabled. My users have no use of a chat system.

I applaud ANZ as their last version of the documentation.  It was much improved.   But I hope to see more additions in the near future.    These are the topics i would find useful.   What topics do you need documented?

I hope everyone views my sharp comments as a way to find better solutions to  help all of us.  But to solve these problems, you need to admit there are problems.

<br> <br>

From what i can see about abp.io, it appears to be a container framework around the backend of aspnetzero. (yes a vast over-simplication). but the backend of the system is not the problem.

The frontend is the problem. the problem is compounded by the fact that the angular specific internal documentation is sparse. im new to angular, but people with years of experience also find it confusing.

if this was an opensource project i would not complain. but i put down my $2500 so i did not have these sort of issues. im fealing tricked!

They keep saying that, this is a starter project, but the nasa logo on the home page, is not a startup company.

i see they just added graphql support. not sure about everyone else, but based on my limited understanding of graphql, im not going to ditch rest api's anytime soon. so why take the time to implement graphql??. they need to focus on supporting EXISTING customers, who pay yearly renewals.

But the problem is, after you use different options, those are merged with the current options, and used next time the dialog is called.

And there is not way to undo this?

Why would anyone want that feature?

The apb.notify. object in Angular is based on toastr library

https://codeseven.github.io/toastr/demo.html

And can be customized by passing a third argument.

var defaultOptions = {
	position: 'top-end',
	showConfirmButton: false,
	timer: 10000,
	padding: 0,
	toast: true,
	animation: false
};
abp.notify.success("The User was succesfully removed.","",defaultOptions);

1. If the "Excluding features using the DI object" is a non starter, I will choose to provide different versions of topbar.component.html. So i can simply not show the relivent sections at the top.

2. You might want to consider adding https://www.uservoice.com/ It would allow the customers to give you feedback on what changes are important and whats not. While i understand that GraphQL is a great technology, it might be voted higher or lower than other topics. The guys who run servicestack.com use it.

3. You really need a FAQ section in your forum. You should create multiple FAQ pages for for Angular, MVC etc. Then topics that keep coming up over and over can be better documented. I keep seeing places where someone comments and links to another post, which links to another post. Its a mess. A FAQ page would be the place where these reoccuring posts can be moved to.

4. Any dates on when Metronic V6 or aspentzero V7 are scheduled to complete?

5. Your company is at a intersting stage in development. You got to where you are by adding new features to attract new customers. But now, you have a lot of customers who all make yearly renewals.. So you need to decide which group you want to continue to make happy. I think you should add more tools and support for your existing customers.

6. If your company is just to "provide a startup template" and its very costly to upgrade templates, few of your existing customers will ever upgrade, and therefor will not see the new features. Why would i continue to pay you yearly support, if you make it difficult to upgrade to the latest template where bugs are fixed and new features added.

Thanks for taking the time to read my comments..

Mitch

@ismcagdas, @maliming -- any comments on my last past would be greatly apprciated!

any update on a FAQ???

I see you're saying this is the fix

https://github.com/aspnetzero/aspnet-zero-core/commit/c4fa5baeb2974c62937fa0be93f6b1439ca4e177

??

There is a fundamental problem here.

Your team see's new features as a benefit, so adding more of them in every release is a good thing.

I view new features as something that i need to, test, document and support, and many of these features don't make sense in my business use case.

I view new features like a menu in a restaurant. I like that I can choose different things to eat, but i don't want to order ALL of them every time i come into the restaurant.   Every time you upgrade i need to go through the process of removing items i don't want from my order.

For example:

• I don't need chat. No user of my system needs to chat with other users.
• Eventually when i have time i will be able to translate my application specific messages to other languages. But currently i don't have time or money for that. So for now, i can only support one language -- English.
• I'm adding my own pages and I don't have time to test my pages with all of the themes that are provided. Therefore I don't want my users to change themes.
• I for one, needs OAuth support, but i imagine many people do not.
• I don't want to support multiple tenants.
• I don't want to require a Captcha
• etc, etc, etc

As i've stated in other posts, i want to support continuous integration and there for do not want to login as admin, and unchecked features in order for the site to be usable.

From reviewing the HTML, I see that some of these feature can be disabled, via ngIf. But its very confusing to figure out whats required to disable each feature.

These are the various techniques i have found that you make use of.

• Some classes require methods that return t/f in each components TS file,
• Some classes call method in AppComponentBase
• Some have site wide changes found in appsettings.json file
• Some have site wide changes found in AppSettingProvider.cs file
• Some have site wide changes found in VenueConsts.cs file
• etc.etc.

And now every-time you come up with a new release, i need to make sure that any of the changes i've made are re-implemented in the new template. So far in 2019 you have updated the template 6 times.

So, i know that you're going to fix the problem with multi-tenants being enabled by default in your 6.9.2 release?   I want to use it since its a problem for me. But i will need to re-implement, test and certify all of the other changes i made.  Its a big mess.

I have some thoughts on how you might consider fixing this problem

1. Make a dependency injected UiConfiguration object that is a single place where all features get enabled or disabled.  Each customer will have their own copy of this.  When new templates are provide you will not provide any changes to this class.  Therefore the merge will be very easy.
2. Make all of your TS classes that derive from AppComponentBase work like this.   Recently we needed  to add functionality such that: when a user is deleted from your backend system, we also delete elements in other systems.    What we did was:
   • Reamed UsersComponent to UsersComponentBase.  Made it private and removed the @Component from this class.
   • Created a new class called UsersComponent in a different file, that derives from UsersComponentBase and added the @Component.
   • Added a new constructor that passes all DI objects to the base class constructor.
   • Overloaded the method deleteUsers.
   • Copied the logic in the base deleteUsers to the overloaded method and made our changes in this method in the new class.

While this is not perfect, it will be much easier to merge this change when a new version of the template is made available because, all changes are separated into a different class.

I'm suggesting that you refactor your entire code base and make those changes.

For every UI component, you would provide a class with no methods and a constructor that simply calls super(args). Customers will have the option to customize the empty class named XXX and ASPNETZERO will update the logic in the class named XXXBase.

This change would not effect existing customers who don't modify the system, but would provide a methodology for supporting changes with customers who must modify the system.

3.  Another variation of the base class trick is this.  We sometimes need versions of your pages that run on different devices  and therefore need a different html or css definitions. What we do is to:

• Rename the base class
• Add a new class
• Change the @component templateUrl and styleUrl definitions point to new locations.

I used this as a way to remove UI elements from the topbar.component.ts file. I used this trick and provided a templateUrl directed to a html file with all of those elements removed.

Conclusion I've been a developer for many many years and I really like your framework. But, as a customers that must make changes to what feature our users see,  its becoming very difficult to support your platform without changes like i've described above. You really should consider providing a technique like ive desribed or something better.

Thanks for your consideration

Mitch