Usability - Solution to use the library as a widget

[app-generator]

Hello @Mortrest

The current version of the library works as a separate page with its own links and actions.

We need to find a solution to provide the same features as a widget where the user can embed this dataTable element in any page.

The NEW requirements:

• Handle any model enabled by Config (as it is now)
• Datatables View can be embedded in any page
• All Exports available

Here are some other packages that look more or less similar:

• https://pypi.org/search/?q=django+datatables (PyPi Search)
• https://pypi.org/project/django-serverside-datatable/
• https://pypi.org/project/django-datatables-serverside/
• https://pypi.org/project/djangorestframework-datatables/

Let's brain storm around these new requirements and let's go.

ty!

[Mortrest]

Hi I have an idea but may be not great. Now, our problem is with rendering HTML of data table and inject it to another HTML pages. We can suppose our datatb as an module that get all required fields in constructors and setters. This object has and .render() function that after embedding parameters in html, return a renderable html string. Client can pass this output to context of his/her template. For example:

from app_generator.datatb import DataTB

class MyView(views.View):
   ...
   def get(self, request):
      ...
      datatb = DataTB(
          title = "sth"
          headings = [...]
          ...
      ).render()
      ...
      return render(
         request, 'some.html', context={
                datatb=datatb
                ...
         }
      )

and In some.html file:

<div>
{{datatb}}
</div>

I think Create, Update and Delete endpoints has no needs to change. because embedded datatb requets to these APIs.

[app-generator]

Looks clean. Some facts we need to take care of:

• The feature needs to target lazy devs and beginners
• We need to keep the current flexibility
  • Minimal Input from user: Model, DB Migration, and Settings Update
• User is not forced to provide header information in view
• If the user updates the model, no change should be required in the view
• The plugin is CSS agnostic
  • can be used with Bootstrap or Tailwind
• The new page should be rendered with an acceptable layout on mobile.

Regarding the coding pattern, might be a good idea to take a look at the existing plugins. We might find a nice pattern.

• https://pypi.org/project/django-serverside-datatable/
• https://pypi.org/project/django-datatables-serverside/
• https://pypi.org/project/djangorestframework-datatables/

Ty guys.

[Mortrest]

We map endpoints to database models so we recognize which model should be viewed by URL. I can't imagine how this data table embed in another page. For example If We are in localhost:8000/index.html and have a frame that data table is rendered in it, which model selects to view? Can you give me an example to show data table is still dynamic and embedded in another page?

[app-generator]

The page where the code runs is irrelevant and we cannot rely on the URI. The library should provide an object where the context is injected.

Your initial snippet is quite closer to this pattern.

from app_generator.datatb import DataTB 

class MyView(views.View):
   ...
   def get(self, request):
      ...
      # here the user provides the MODEL 
      datatb = DataTB(
          title = "sth"
          dataSrc="Products"    # <-- Model here
      )
      ...
      return render(
         request, 'some.html', context={
                datatb=datatb.render()         # <-- the MAGIC is provided by "render()" helper
                ...
         }
      )

Note that we might have multiple DataTB controls on the same page.

P.S. definitely not a boring task, right? 🚀🚀

[Mortrest]

Nice. Your idea sounds great. Do you think I should implement it this way?

[app-generator]

Yes @Mortrest

Let's code it this way.

Ty guys!

[app-generator]

P.S. Just a small additional information

The syntax for the model managed by the widget should provide a full import PATH:

from app_generator.datatb import DataTB 

class MyView(views.View):
   ...
   def get(self, request):
      ...
      # here the user provides the MODEL 
      datatb = DataTB(
          title = "sth"
          dataSrc="app1.models.Book"    # <-- FULL Path here
      )
      ...

The model being provided by the developer, the check in the CFG becomes obsolete (no more check if the MODEL was activated in the settings):

DYNAMIC_DATATB = {
    # SLUG -> Import_PATH 
    'books'  : "app1.models.Book",
}

Ty Guys!

[Mortrest]

Hi Using multiple data tables in one page needs many efforts. Because everything is dynamic. Should we make these efforts?

[app-generator]

Hello @Mortrest let's have a stable version for a single widget first. We can postpone this use-case being complex and warn the users to use a single widget/page.

P.S. I know that this task is a hell of a job. Moving in small steps is wiser.

Ty for the efforts.

[app-generator]

Hello @Mortrest, @mchoopani all good with the task?

[Mortrest]

Hello Yes. We prepare a single widget version of this project asap.

[app-generator]

🚀🚀

[Mortrest]

Hi Please review the pull request and give your comments. Thanks.

[app-generator]

Hello @mchoopani

Trying to use ... some imports are missing. The latest commits were merged to HEAD and released.

Please fully configure this sample project to showcase the feature:

https://github.com/app-generator/django-dynamic-services

Ty!

[Mortrest]

OK I see some bugs while preparing the test project. We will fix the bugs, then inform you to run the project. Thank You

[app-generator]

Ty @Mortrest 🚀🚀

[Mortrest]

You can see using of DataTB module in this Pull Request.

[app-generator]

Guys ... the feature works. Ty for all the work. is impressive.

A single issue remains. The widget is not rendered to fill the entire available space.

The latest version of the sample showcases this problem. Things that need to be done to have a production-ready library

• Layout on AdminLTE fixed
• Test & FIX Layout using other BS5 kits (2 or three)
• Support Tailwind and let the user choose the layout styling (via config, with defaults on BS)

All the new tasks are budgeted separately. For now, let's fix the UI for AdminLTE.

Ty! @Mortrest @mchoopani @

[app-generator]

Hello Team,

Some issues are fixed, but the library is far from production-ready. Here are the issues:

• The layout is styled in different places and the code looks dirty and hard to follow
• The old routing that uses the whole page is not working anymore
  • This feature needs to be preserved
• The UI needs refactoring using flexbox in all components
  • Like this, the UI remains consistent in all containers.

Let me know if the team is able to deliver the above items.

Ty!

[app-generator]

P.S. The codebase was updated to patch somehow the UI. Please pull the latest changes.

[app-generator]

Closing