Looking for things to implement at Yii hackathon

There’s going to be Yii hackathon in Moscow soon and I’m collecting various cool ideas for extensions and things to improve.

We’re going to work on https://github.com/yiisoft/yii2-queue but that doesn’t look like enough.

What are you missing in Yii that could be solved in about 8 hours by experienced team?

Please finish the queue. This is a must, i am sick of using third party libs for such basic need, this has to be in core.

Next, how about a cron job handler library, like jobby, or maybe built on top of jobby?

This, combined with the queue, will make wonders.

A cart library that would store info in the database so that we can use it for rest services as well. Nice interface to it to implement our own items.

A payment library where payment processors would be easily implemented by following certain interface/abstract classes.

These are real problems developers have to tackle in projects. The framework should make all this much easier for us.

Noted about crontab.

A good shopping cart is already there: https://github.com/omnilight/yii2-shopping-cart. It probably could be adjusted to be more storage agnostic. Noted.

A payment library is this http://omnipay.thephpleague.com/. Not sure what’s to be added for it to be used with Yii. I saw projects where it’s used w/o any wrappers and it’s fine.

what about improving or building an advanced extension for REST ?

many features are already requested like nested routing, nested expand for fields and filtering results. In github they are treated separately by proposing extra code to each of them but I think they are kind of related and they would be better solved within a good solution by design.

Filtering may only need involving a SearchClass object as it is done with non REST controllers but if nested routing is solved (my attempt is this) then a URL like:

GET /parent/<parent_id>/model/<id> 

is a valuable information to also solve nested expand for fields by pre-setting scenarios to which fields should be expended in a way we can keep control of app authorizations.

@creocoder mentioned a different aproach called transformers here by differently representing one model to several resources and I think it may be a wonderful solution.

I’m not sure what kind of meeting is the Yii hackathon but what I’m trying to say is maybe all those requested REST features should be discussed all at once as an experienced team will be meeting.


Suggestion to add multi-level relations to ActiveRecord::extraFields()

=> https://github.com/yiisoft/yii2/issues/3303

salem, that’s an important topic but is too broad to solve anything of it at once.

ok then what about something built with Yii to be implemented in the new Yii website ?

like maybe a better forum or a smart searching page based on specified tags to get wikis, forum posts, extensions (maybe using also github api like yiigist.com is doing), or …

Yes. Could be done.

@samdark I have another idea about REST but I’m not sure if it is good or not for a Yii hackathon so I’ll just throw it here because I also need your feedback about it.

I like using the basic template for REST. I keep the web folder as it is to be able to use gii to generate models, views, … the generated web controllers are useful to quickly add/update data and it is always useful to keep access to gii as you may need it later.

Then I build an api folder for REST with its own entry script, config file, routing rules, modules, controllers, some models,… (exactly as it is done in this tutorial) and when the app should go to production I just delete the web folder and keep only the api folder (+ an auth folder which role is deliver refresh and access tokens but that is a different story).

Recently I found this great extension: https://github.com/zhuravljov/yii2-rest so I started thinking about this: why not building a custom template for REST where the web folder is entirely used to build and debug the REST api then remove it when the REST app is production ready. the web folder in this case should be a built-in application that does the following:

1- has a built-in actions (or custom version of gii) to generate the api folder and related modules (v1,V2,…), config file…

2- has built-in actions to build resources on the fly (which means creating tables into database, maybe also generating migration scripts, controllers, models,…) and actions to add/update/delete data. the full picture can be seen by watching the first minute of this video which gives a preview of how deployd works. the idea is to do almost the exact same within a Yii web app.

3- uses the yii2-rest extension to debug the api BUT the debugger tool bar should not debug the web folder related app. somehow it should collect and preview logs related to the api folder.

About 3 I don’t know if it is possible using the current yii2-debug extension and knowing that session should be disabled in the api related config file (at least when production ready). and this is why I’ll be grateful if I get your feedback about it so I may try doing it myself if it is possible but out of the Yii hackathon.

Not really suitable for Yii hackathon but a good idea.

ok thanks I’ll learn more about yii2-debug tool as I only used Yii2 for REST so far so I don’t know yet how it works. then I’ll see if I can make an extension, maybe yii2-api-builder that works like strapi.io or deployed, then a template yii2-advanced-rest with a simple bearer authentication and where the builder is integrated by default. then we will see if it works.

Another feature (enhancement) that should be implemented is an improvement to the method Model::load()

Actually when you load data from a form (or also when you assign directly the value if you do not cast the datatype) all the number coming from it are loaded as string making the attributes dirty even if is not changed.

This make more difficult making control on it using dirty check method and in plus it cause to run update query when data are not changed.

I know you can make filters to cast them to the appropriate type but this is a redundant action that practically is always needed for optimal coding

But since the model knows the datatype filed should be automatically casted.

Don’t know if this is big enough for hackathon, but for sure is a must that is going to save a lot of time (and error) during coding.

Roberto Braga

It could be a good idea for 2.1. Can you submit it to github issue tracker?