Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TBS project development #21

Open
2 of 16 tasks
roxblnfk opened this issue Dec 16, 2020 · 0 comments
Open
2 of 16 tasks

TBS project development #21

roxblnfk opened this issue Dec 16, 2020 · 0 comments

Comments

@roxblnfk
Copy link
Contributor

roxblnfk commented Dec 16, 2020

Hi @Skrol29 i read your post that you often think about project development.
This is great, and I would like to speculate about how it looks to me. Perhaps you are interested in something from what is written below.

Let's start with what the first steps would be nice to take:

  • Create an organization tinybutstrong on github. It's free.

    • Move all TBS repositories there. (Repository Settings -> Options -> Transfer ownership)
    • Enable Discussions for repositories.
    • You can also add maintainers so that you don't have to pull the project alone. For example, i will gladly join and devote part of my free time.
  • Prepare codebase.

    • Create a project structure according to PSR-4 (move classes to tinybutstrong namespace).
    • For version 3.x, keep the classes in the same namespace, but mark them with @deprecated. They will inherit from classes from the tinybutstrong namespace. All deprecated will be removed or hidden in the next major release.
    • For version 3.x, create the tbs-3 branch. Development of version 4 will be in the master branch.
    • For TBS 4, you can immediately set the php version ^7.4|^8.0 and not look back.
  • Create roadmap.

    • First of all, you need to decide what things need to be thrown away. Removing them from the code immediately makes refactoring easier.
    • Determine what functions to save and what new features to add in the project. In part, this concerns not the code itself, but the syntax, workflow and api in general.
    • If you know active TBS users, then you can try to get feedback from the community.
    • There may come a time when it will be necessary to decide: rewrite everything from scratch or decompose and refactor what is.
      I have some suggestions (see below) that, in my opinion, are very cool, but for their implementation it is necessary to revise the entire code.

As a result of drawing up the Roadmap, i see the following options for developing new versions:

  • Conservative development v4: a gradual rewriting of the code with decomposition and refactoring. Without huge changes, but with major improvements. Implementation of advanced testing techniques and static analysis.
  • Innovative development v4: a complete redesign of the template engine. Implementation of killer features, processing of the gained experience into a new product.
  • Development of conservative version 4 and innovative version 5.

What suggestions for changes do i mean?

  • The hardest and most serious thing is streamed templating. The merge process will not be the same as before.
    TBS will not merge data immediately after calling the merge method.
    First, we prepare all data, and then we start the merge process. The search for markers and their replacement will occur on the fly.
    In this case, you will not need to store the generated part of the document in memory. What do we get from this?

    • Less memory consumption and more performance.
    • Generation of endless (very big) excel files without going out of memory (killer feature). Yes, in php create zip archives in a stream.
    • It will be possible to merge the same blocks several times.
  • Add more abstractions when working with data.
    I suggest using the DataReader/DataWriter interfaces from the Yii Framework and separate modifiers to offload the templating code.
    For example, the code for working with the database will disappear from TBS, but their support will remain. The template engine doesn't care where the data comes from.
    At the same time, this data can be easily sorted, limited and filtered if DataReader implements appropriate interface (SortableDataInterface, FilterableDataInterface...).

  • Add support for PSR logger. Errors should not be emitted into the output, they should be logged.

  • Add PSR-7 support to return the template file as a ResponseInterface object.

Here's some more food for thought:

  • You can create a fund on opencollective to raise funds for the development of the project, as many open source projects do.
  • In my TBS fork, i implemented sorting, filtering and grouping of block data.
    There is very bad documentation (this is my weak point), but everything is covered by tests and works very good.
    I use these functions to generate payment receipts and reports in one of the projects.
    If you are interested add this funcitons into v3, i can do a PR, but the documentation is still bad for me.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant