github.com/sapplications/sb@v0.0.0-20240116135441-1a13cafe3497/TODO.txt (about) 1 improvements & bugs 2 3 4 BAD IDEA: ADD THE ABILITY TO GENERATE SOME CODE BY THE COMPONENT - depends on the input parameter? Use the external application (code generator) for that? 5 BETTER IDEA: use internal fields for matching them with the dependent params. The internal fields should be initialized before that. 6 So, describe the matching mechanism. 7 Or use reflection? Better to avoid reflection! 8 9 Use array of interface{} for initializing the struct. So, check each item and try to convert to the correct type. 10 Or, push the above array to the dependent component? 11 12 USE STRUCT META/TAG IN GOLANG FOR FIELDS! 13 If dependent item includes required field, then the owner should initialize it using field tag 14 Or field with tag should be used for item initialization 15 If the field tag is an array then process all item fields using this tag array 16 17 ------------------------- 18 19 Add the ability to internaly initialize parameters in function 20 21 func(path/pkg.NewStruct { 22 ...initialization 23 }) 24 25 ------------------------- 26 27 Execute function of the current instance use the following syntax 28 29 . FUNC_NAME() 30 31 If the field name starts with dot then the resolver must be a function of the current instance. 32 This function should be performed. Try to keep the order of dependency items. 33 34 Example, 35 36 sb.Starter.AddCommand(&sb.Creator.Command) 37 >> 38 . AddCommand(*path/pkg.sb.Creator.Command) 39 OR 40 . AddCommand(*path/pkg.NewStruct { 41 ...initialization 42 }) 43 44 ----------------------------- 45 46 core features 47 - add a new "gbuild" command to perform generate and build commands 48 - use field tag to mark the required fields? 49 50 smart features 51 - add metadata to a struct to describe its functionality (use it for generating apps!) 52 - use "application", "feature", and "action" items for describing application requirements 53 - "application" - kind of application. It includes a set of features 54 - "feature" - application feature. It includes a set of actions 55 - "action" - to do a work 56 - the smart builder behavior: 57 - read smart builder application unit using smodule package? 58 - read all smart package units using smodule package? 59 - generate smart builder unit according to the requirements and available smart packages 60 - create "sapp" package for that 61 - build the application 62 63 tests 64 - list all tests (update the build system) 65 66 help 67 - .sa - smart application unit. Includes a declarative syntax for describing the application 68 - .sb - smart builder unit. It can be generated using .sa unit. 69 - .sp - smart package unit. It will be created manually but it should be generated in the future. 70 Describes the exported items. The smart builder will use it for generating .sb unit. 71 72 example of sa file 73 sa 74 75 apps: 76 helloworld 77 78 helloworld: 79 name helloworld - optional, default the same as app name 80 type console - optional, default is console 81 coder sgo - optional, default is sgo 82 entry helloworld/actions - optional, default is [appname/actions] 83 features helloworld/features - optional, default is [appname/features] 84 85 helloworld/actions: 86 // sb will supports some common actions 87 print "Hello World!" 88 89 helloworld/features: 90 // describe all supported features 91 // the console implementation depends on the current list of features 92 commands ... 93 database ... 94 logger ... 95 interaction ...