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
Need to create a better loader object management layer and then refactor the perform.._load methods (e.g perform_excel_load) as these currently do too much.
Look for a good pattern for Object Management, move out of loaders/Populator, into separate area.
Enable loaders to reach into this to grab current object, split out from the generic loaders, and provide hooks in those generic Loaders to enable custom loaders to more easily manage the object lifecycle themselves. Currently far too rigid, i.e just creates a new object for each row processed.
The text was updated successfully, but these errors were encountered:
Hi there ... yes it's well under way, see branch split_into_concerns, but it would be great to have some help, as still alot of work to do.
Not too sure right now how to direct where .. the improved support classes taking shape, and I think LoaderBase and Excel loader on way to being fully migrated to use them
I'll try and put together a sort of roadmap/class diagram to help
I am slowly looking at implementing this.
Need to create a better loader object management layer and then refactor the perform.._load methods (e.g perform_excel_load) as these currently do too much.
Look for a good pattern for Object Management, move out of loaders/Populator, into separate area.
Enable loaders to reach into this to grab current object, split out from the generic loaders, and provide hooks in those generic Loaders to enable custom loaders to more easily manage the object lifecycle themselves. Currently far too rigid, i.e just creates a new object for each row processed.
The text was updated successfully, but these errors were encountered: