You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
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.
The text was updated successfully, but these errors were encountered:
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.Prepare codebase.
@deprecated
. They will inherit from classes from thetinybutstrong
namespace. Alldeprecated
will be removed or hidden in the next major release.tbs-3
branch. Development of version 4 will be in themaster
branch.^7.4|^8.0
and not look back.Create roadmap.
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:
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?
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:
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.
The text was updated successfully, but these errors were encountered: