joomla/Component-Builder

Fork 11

Super Powers Needed in JCB #984

New Issue

Closed

opened 2023-03-11 16:31:27 +00:00 by Llewellyn · 5 comments

Llewellyn commented

2023-03-11 16:31:27 +00:00

Owner

Joomla Component Builder (JCB), has super powers. Which is another way of saying it now allows for powers to be pulled in from a global array of areas, over which you have full control. This allows for easy sharing of your powers between your JCB instances with your own power repositories on https://git.vdm.dev/[username]/my-powers. While at the same time be able to use the JCB core powers where needed.

Let's explain:
This feature called super-powers, manages powers by use of layers, events, tasks, methods, switches, and algorithms that all work in combination of different ways to achieve super powers.

The [powers] are:

[guid] => Each power has a global unique identifier used to control the power global identity. This [power:guid] looks like this: b836c1b1-b6b1-44f7-b8a2-9a763a4185b1
[code] => The actual code of the power that is found in a PHP file
[settings] => The settings define the power details, relationships, and more. They are stored in a Json formatted file in [layer:repo] and/or [layer:local] and/or as column values in the [layer:database]

The [layers] are:

[database] This JCB instance's Database
[repo] The https://git.vdm.dev/ git website that holds all repos, and which is managed by Vast Development Method
[core] The core super-power repo of JCB https://git.vdm.dev/joomla/super-powers (soon...)
[own] Your own super-powers repos https://git.vdm.dev/[username]/my-powers (sub-paths)
[local] Local path, and its sub-paths that hold [core] and [own] repositories.

The [events] are:

[compile] Compilation of a component
[sync] Synchronisation of selected powers with [algorithm:cascading]
[init] Uploads all powers from all active [layers] into [layer:database] if not already exist in [layer:database]
[reset] Force synchronisation of selected powers with [layer:core]

The [tasks] are:

[get] To get powers from any of the layers
[set] To set powers to database or local paths

The [methods] are:

[auto] When JCB automatically does this for you
[manual] When you must manually do something

The [switches] are:

[activate] This switch activates super-powers, and allows for [layer:local] path to be set
[token] This is the VDM access token from the global tab.
[super] This switch allows for [layer:own] paths to be set
[approved] This switch allows a power to be added to a [layer:core] or [layer:own] paths

The [algorithms] are:

[cascading] The is the way in which JCB [task:get] a power during the [events] so that it can use the power in your component, and store in [layer:database]

These terminologies and ideas are what you need to remember whenever you read any of the comments and other information about super-powers in JCB.

JCB uses powers as the foundation of all it builds. You can build things with JCB without knowing how to use or work with powers. But JCB cannot build anything without powers. That means JCB needs to load powers from the [layer:core] and usually will do this whenever an [event] is triggered based on the [algorithm:cascading].

All these events can possibly move powers into your [layer:database]. These [events] have the [method:auto] behaviour, and therefore we make use of the [algorithm:cascading] that allows for overriding any power in any way you like. Beware that divergence from the core powers may have side effects and therefore should only be done with knowledge and full understanding on your part.

Let's Explain the [algorithm:cascading]
During [events] we must [auto] load powers, and so there is a search path for each event.

The [event:compile] when building your component, here is the [algorithm:cascading]:

[layer:database]
[layer:local IF switch:activate AND switch:approved]
[layer:own IF switch:token AND switch:activate AND switch:super AND switch:approved]
[layer:core]

This means, that if JCB gets a [power:guid] in the [layer:database] it stops the search and uses that found power. But if not, it will continue until it finds the power, or it will show an error that the power could not be found. Once it finds the power, it will make sure that the power is in [layer:database], and if [layer:local] is active, it will update those as well as determined by the approved path selection of each power.

The [event:sync] when the sync button is clicked, here is the [algorithm:cascading]:

[layer:own IF switch:token AND switch:activate AND switch:super AND switch:approved]
[layer:local IF switch:activate AND switch:approved]
[layer:core]

This means, that if JCB gets a [power:guid] in any of the targeted [layer:own] it stops the search for that power at the first instance it finds that power. Then JCB will update your [layer:database] with the found power, irrespective of modify or creation date. The [power:guid] is used as the key, and should JCB therefore have a power in any of your [layer:own] it will override the [layer:core] and [layer:local] version of any power, and update the [layer:database].

The [event:reset] when the reset button is clicked, will update [layer:database] with [layer:core] version of the selected powers if found in [layer:core], irrespective of modify or creation date.

The [event:init] when the init button is clicked, will initialise [layer:database] with all [layers] powers not found in [layer:database]. Should you have the same power in multiple of the layers, here is the [algorithm:cascading]:

[layer:own IF switch:token AND switch:activate AND switch:super AND switch:approved]
[layer:local IF switch:activate]
[layer:core IF_NOT layer:database]

This means, that if JCB gets a [power:guid] in any of the targeted [layer:own] it will not use any of the other [layers] versions. JCB will add this first found power to your [layer:database] unless it's already in [layer:database], in which case it will be ignored. Use [event:sync] or [event:reset] should you like to update [layer:database] existing powers.

Joomla Component Builder (JCB), has **super powers**. Which is another way of saying it now allows for powers to be pulled in from a global array of areas, over which you have full control. This allows for easy sharing of your powers between your JCB instances with your own power repositories on https://git.vdm.dev/[username]/my-powers. While at the same time be able to use the JCB core powers where needed. Let's explain: This feature called **super-powers**, manages powers by use of layers, events, tasks, methods, switches, and algorithms that all work in combination of different ways to achieve super powers. The **[powers]** are: - [guid] => Each power has a global unique identifier used to control the power global identity. This [power:guid] looks like this: *b836c1b1-b6b1-44f7-b8a2-9a763a4185b1* - [code] => The actual code of the power that is found in a PHP file - [settings] => The settings define the power details, relationships, and more. They are stored in a Json formatted file in [layer:repo] and/or [layer:local] and/or as column values in the [layer:database] The **[layers]** are: - [database] This JCB instance's Database - [repo] The https://git.vdm.dev/ git website that holds all repos, and which is managed by Vast Development Method - [core] The core super-power repo of JCB https://git.vdm.dev/joomla/super-powers (soon...) - [own] Your own super-powers repos https://git.vdm.dev/[username]/my-powers (sub-paths) - [local] Local path, and its sub-paths that hold [core] and [own] repositories. The **[events]** are: - [compile] Compilation of a component - [sync] Synchronisation of selected powers with [algorithm:cascading] - [init] Uploads all powers from all active [layers] into [layer:database] if not already exist in [layer:database] - [reset] Force synchronisation of selected powers with [layer:core] The **[tasks]** are: - [get] To get powers from any of the layers - [set] To set powers to database or local paths The **[methods]** are: - [auto] When JCB automatically does this for you - [manual] When you must manually do something The **[switches]** are: - [activate] This switch activates super-powers, and allows for [layer:local] path to be set - [token] This is the VDM access token from the global tab. - [super] This switch allows for [layer:own] paths to be set - [approved] This switch allows a power to be added to a [layer:core] or [layer:own] paths The **[algorithms]** are: - [cascading] The is the way in which JCB [task:get] a power during the [events] so that it can use the power in your component, and store in [layer:database] These terminologies and ideas are what you need to remember whenever you read any of the comments and other information about super-powers in JCB. JCB uses powers as the foundation of all it builds. **You can build things** with JCB without knowing how to use or work with powers. But **JCB cannot build anything** without powers. That means JCB needs to load powers from the [layer:core] and usually will do this whenever an [event] is triggered based on the [algorithm:cascading]. All these events can possibly move powers into your [layer:database]. These [events] have the [method:auto] behaviour, and therefore we make use of the [algorithm:cascading] that allows for overriding any power in any way you like. Beware that divergence from the core powers may have side effects and therefore should only be done with knowledge and full understanding on your part. Let's Explain the **[algorithm:cascading]** During [events] we must [auto] load powers, and so there is a search path for each event. The **[event:compile]** when building your component, here is the **[algorithm:cascading]**: 1. [layer:database] 2. [layer:local IF switch:activate AND switch:approved] 3. [layer:own IF switch:token AND switch:activate AND switch:super AND switch:approved] 4. [layer:core] This means, that if JCB gets a [power:guid] in the [layer:database] it stops the search and uses that found power. But if not, it will continue until it finds the power, or it will show an error that the power could not be found. Once it finds the power, it will make sure that the power is in [layer:database], and if [layer:local] is active, it will update those as well as determined by the approved path selection of each power. The **[event:sync]** when the sync button is clicked, here is the **[algorithm:cascading]**: 1. [layer:own IF switch:token AND switch:activate AND switch:super AND switch:approved] 2. [layer:local IF switch:activate AND switch:approved] 3. [layer:core] This means, that if JCB gets a [power:guid] in any of the targeted [layer:own] it stops the search for that power at the first instance it finds that power. Then JCB will update your [layer:database] with the found power, irrespective of modify or creation date. The [power:guid] is used as the key, and should JCB therefore have a power in any of your [layer:own] it will override the [layer:core] and [layer:local] version of any power, and update the [layer:database]. The **[event:reset]** when the reset button is clicked, will update [layer:database] with [layer:core] version of the selected powers if found in [layer:core], irrespective of modify or creation date. The **[event:init]** when the init button is clicked, will initialise [layer:database] with all [layers] powers not found in [layer:database]. Should you have the same power in multiple of the layers, here is the **[algorithm:cascading]**: 1. [layer:own IF switch:token AND switch:activate AND switch:super AND switch:approved] 2. [layer:local IF switch:activate] 3. [layer:core IF_NOT layer:database] This means, that if JCB gets a [power:guid] in any of the targeted [layer:own] it will not use any of the other [layers] versions. JCB will add this first found power to your [layer:database] unless it's already in [layer:database], in which case it will be ignored. Use [event:sync] or [event:reset] should you like to update [layer:database] existing powers.

👍 3

Llewellyn commented

2023-03-11 20:01:51 +00:00

Author

Owner

How should the format look like of the repository?

Here is my current idea:

@startwbs
* Repository
** src
*** b836c1b1-b6b1-44f7-b8a2-9a763a4185b1
**** code.php
**** settings.json
*** de01527a-6586-46ea-92e7-11ea3de1cedb
**** code.php
**** settings.json
*** 1133c2d7-ba7e-4c95-8cde-01f084d04682
**** code.php
**** settings.json
** super-powers.json
** README.md
@endwbs

What each part will mean:

@startuml
frame "Repository" {
  folder "src" {
    folder "Power" {
      file "settings.json" {
        label "linking details and more"
      }
      file "code.php" {
         label "<?php ... ?>"
    }
  }
}
file "super-powers.json" {
  label "powers index"
}
file "README.md" {
  label "repo detailed instructions"
}
@enduml

How should the format look like of the repository? ##### Here is my current idea: ```uml @startwbs * Repository ** src *** b836c1b1-b6b1-44f7-b8a2-9a763a4185b1 **** code.php **** settings.json *** de01527a-6586-46ea-92e7-11ea3de1cedb **** code.php **** settings.json *** 1133c2d7-ba7e-4c95-8cde-01f084d04682 **** code.php **** settings.json ** super-powers.json ** README.md @endwbs ``` ##### What each part will mean: ```uml @startuml frame "Repository" { folder "src" { folder "Power" { file "settings.json" { label "linking details and more" } file "code.php" { label "<?php ... ?>" } } } file "super-powers.json" { label "powers index" } file "README.md" { label "repo detailed instructions" } @enduml ```

Llewellyn commented

2023-03-21 22:57:28 +00:00

Author

Owner

Okay so the first demonstration of JCB build super powers has happened, you can see it in these two repositories:

Okay so the first demonstration of JCB build super powers has happened, you can see it in these two repositories: - https://git.vdm.dev/joomla/jcb-compiler - https://git.vdm.dev/joomla/super-powers

Llewellyn commented

2023-03-21 23:00:44 +00:00

Author

Owner

I think you will enjoy these two new classes, that is doing all the heavy lifting to make this work:

final class Parser a basic php class parser
class Plantuml a basic uml builder

I think you will enjoy these two new classes, that is doing all the heavy lifting to make this work: - [final class Parser](https://git.vdm.dev/joomla/jcb-compiler/src/branch/master/src/95d0e03f-24fd-4412-bc2e-f0899fcc3205) a basic php class parser - [class Plantuml](https://git.vdm.dev/joomla/jcb-compiler/src/branch/master/src/ff5e9e63-86d0-4691-ab59-d4b9d9154096) a basic uml builder

Llewellyn commented

2023-03-21 23:03:00 +00:00

Author

Owner

There is really still so much room for growth, but this will have to do as we now need to move on to the function in JCB that will use these repositories.

I will push out the beta with that builds these repositories in the next few days.

There is really still so much room for growth, but this will have to do as we now need to move on to the function in JCB that will use these repositories. I will push out the beta with that builds these repositories in the next few days.

Llewellyn commented

2023-03-24 01:24:45 +00:00

Author

Owner

Okay we just finished the gitea API backend:

https://git.vdm.dev/joomla/gitea

Okay we just finished the gitea API backend: https://git.vdm.dev/joomla/gitea

👍 1