Skip to content

Fix issue #524 - Add support for working with types packed into an object to the standard adapter - #645

Merged
andrerav merged 2 commits into
MapsterMapper:developmentfrom
DocSvartz:ObjectModFix
Jan 3, 2025
Merged

Fix issue #524 - Add support for working with types packed into an object to the standard adapter#645
andrerav merged 2 commits into
MapsterMapper:developmentfrom
DocSvartz:ObjectModFix

Conversation

@DocSvartz

@DocSvartzDocSvartz commented Oct 18, 2023

Copy link
Copy Markdown
Contributor

Fix issue #524

Before:

if Type was packaged into an object:

object _source = new TSource()

Instead of updating with data from TSource, it was converted to the TDestination type

_source.Adapt(_destination) == _source.Adapt<TDistination>

@DocSvartzDocSvartz changed the title Fix #524 - Added support Update function TDistination in Object AdapterFix issue #524 - Added support Update function TDistination in Object AdapterOct 19, 2023
@DocSvartzDocSvartz changed the title Fix issue #524 - Added support Update function TDistination in Object AdapterFix issue #524 - Added support Update function TDestination in Object AdapterOct 20, 2023
@DocSvartzDocSvartz changed the title Fix issue #524 - Added support Update function TDestination in Object AdapterAdded support Update function TDestination in Object AdapterOct 20, 2023
@DocSvartzDocSvartz changed the title Added support Update function TDestination in Object AdapterFix issue #524. Adding support for working with Types packed into an object to the standard adapterOct 20, 2023
@DocSvartz

Copy link
Copy Markdown
ContributorAuthor

Seems like, It was simply necessary to apply an already developed solution. By adding it to a standard adapter. :)

@DocSvartz

DocSvartz commented Oct 21, 2023

Copy link
Copy Markdown
ContributorAuthor

Hello @andrerav
It looks like the simplest and most correct solution would actually be to use the mechanism from the special overload of the Adapt Method.

  1. In general, the Expression for an adapt is created based on the types of generic arguments.
    With this call, generation will always occur for the object type as a TSource or TDestination. Since the generic method was called for them: Adapt<object,TDestination>(), Adapt<object,object>(), Adapt<TSource ,object> ( but not Adapt<TSource,TDestination>().
  2. The received conversion Adapt function is called with Runtime arguments (variables) passed for updating.
    But since the Adapt function has already been generated for the Object type, processing for it will occur as an Object.

Therefore, this is not exactly an ObjectAdapter problem, as I initially decided.
You just need to initially generate the Adapt function for the Type Packed into an object ( TSource or TDestination )

  1. Even to call a function dynamically, need to know the real type of the TSource before calling them.
    Without this cannot create this:
var method = (from m in typeof(TypeAdapterConfig).GetMethods(BindingFlags.Instance | BindingFlags.Public)
where m.Name == nameof(GetMapToTargetFunction)
select m).First().MakeGenericMethod(sourceType, destinationType);

The main problem is the following:
For this to work, need to capture the Runtime type of variables _source.GetType() _destination.GetType() somewhere and save them for subsequent construction of the Adapt function (Theory, maybe this won't work either).

@DocSvartz

DocSvartz commented Oct 21, 2023

Copy link
Copy Markdown
ContributorAuthor

@andrerav It looks like now the work on the fix is really complete.

Update:
I left the endless loop breaker in both places, for greater reliability - in ObjectAdapter this not required

@andrerav

Copy link
Copy Markdown
Member

@DocSvartz Could you please resolve this merge conflict when you have time? Looks like it should be fairly trivial :)

@andreravandrerav changed the title Fix issue #524. Adding support for working with Types packed into an object to the standard adapterFix issue #524 - Add support for working with types packed into an object to the standard adapterJan 3, 2025
@andrerav
andrerav merged commit 3bf9e6b into MapsterMapper:developmentJan 3, 2025
@andrerav

Copy link
Copy Markdown
Member

Thank you @DocSvartz!

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@DocSvartz@andrerav
, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Fix issue #524 - Add support for working with types packed into an object to the standard adapter by DocSvartz · Pull Request #645 · MapsterMapper/Mapster · GitHub
Skip to content

Fix issue #524 - Add support for working with types packed into an object to the standard adapter - #645

Merged
andrerav merged 2 commits into
MapsterMapper:developmentfrom
DocSvartz:ObjectModFix
Jan 3, 2025
Merged

Fix issue #524 - Add support for working with types packed into an object to the standard adapter#645
andrerav merged 2 commits into
MapsterMapper:developmentfrom
DocSvartz:ObjectModFix

Conversation

@DocSvartz

@DocSvartzDocSvartz commented Oct 18, 2023

Copy link
Copy Markdown
Contributor

Fix issue #524

Before:

if Type was packaged into an object:

object _source = new TSource()

Instead of updating with data from TSource, it was converted to the TDestination type

_source.Adapt(_destination) == _source.Adapt<TDistination>

@DocSvartzDocSvartz changed the title Fix #524 - Added support Update function TDistination in Object AdapterFix issue #524 - Added support Update function TDistination in Object AdapterOct 19, 2023
@DocSvartzDocSvartz changed the title Fix issue #524 - Added support Update function TDistination in Object AdapterFix issue #524 - Added support Update function TDestination in Object AdapterOct 20, 2023
@DocSvartzDocSvartz changed the title Fix issue #524 - Added support Update function TDestination in Object AdapterAdded support Update function TDestination in Object AdapterOct 20, 2023
@DocSvartzDocSvartz changed the title Added support Update function TDestination in Object AdapterFix issue #524. Adding support for working with Types packed into an object to the standard adapterOct 20, 2023
@DocSvartz

Copy link
Copy Markdown
ContributorAuthor

Seems like, It was simply necessary to apply an already developed solution. By adding it to a standard adapter. :)

@DocSvartz

DocSvartz commented Oct 21, 2023

Copy link
Copy Markdown
ContributorAuthor

Hello @andrerav
It looks like the simplest and most correct solution would actually be to use the mechanism from the special overload of the Adapt Method.

  1. In general, the Expression for an adapt is created based on the types of generic arguments.
    With this call, generation will always occur for the object type as a TSource or TDestination. Since the generic method was called for them: Adapt<object,TDestination>(), Adapt<object,object>(), Adapt<TSource ,object> ( but not Adapt<TSource,TDestination>().
  2. The received conversion Adapt function is called with Runtime arguments (variables) passed for updating.
    But since the Adapt function has already been generated for the Object type, processing for it will occur as an Object.

Therefore, this is not exactly an ObjectAdapter problem, as I initially decided.
You just need to initially generate the Adapt function for the Type Packed into an object ( TSource or TDestination )

  1. Even to call a function dynamically, need to know the real type of the TSource before calling them.
    Without this cannot create this:
var method = (from m in typeof(TypeAdapterConfig).GetMethods(BindingFlags.Instance | BindingFlags.Public)
where m.Name == nameof(GetMapToTargetFunction)
select m).First().MakeGenericMethod(sourceType, destinationType);

The main problem is the following:
For this to work, need to capture the Runtime type of variables _source.GetType() _destination.GetType() somewhere and save them for subsequent construction of the Adapt function (Theory, maybe this won't work either).

@DocSvartz

DocSvartz commented Oct 21, 2023

Copy link
Copy Markdown
ContributorAuthor

@andrerav It looks like now the work on the fix is really complete.

Update:
I left the endless loop breaker in both places, for greater reliability - in ObjectAdapter this not required

@andrerav

Copy link
Copy Markdown
Member

@DocSvartz Could you please resolve this merge conflict when you have time? Looks like it should be fairly trivial :)

@andreravandrerav changed the title Fix issue #524. Adding support for working with Types packed into an object to the standard adapterFix issue #524 - Add support for working with types packed into an object to the standard adapterJan 3, 2025
@andrerav
andrerav merged commit 3bf9e6b into MapsterMapper:developmentJan 3, 2025
@andrerav

Copy link
Copy Markdown
Member

Thank you @DocSvartz!

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@DocSvartz@andrerav
, 'i'); if (__m === '*' || __re.test(location.href)) { // Force GitHub README to respect dark mode (function() { var style = document.createElement('style'); style.textContent = ' .markdown-body { color-scheme: dark light; } .markdown-body pre { background: #161b22 !important; } .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; } .markdown-body table th, .markdown-body table td { border-color: #30363d !important; } .markdown-body img { background: #0d1117; } .markdown-body blockquote { border-left-color: #8b949e; } .markdown-body hr { border-color: #30363d; } '; document.head.appendChild(style); })(); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' Fix issue #524 - Add support for working with types packed into an object to the standard adapter by DocSvartz · Pull Request #645 · MapsterMapper/Mapster · GitHub
Skip to content

Fix issue #524 - Add support for working with types packed into an object to the standard adapter - #645

Merged
andrerav merged 2 commits into
MapsterMapper:developmentfrom
DocSvartz:ObjectModFix
Jan 3, 2025
Merged

Fix issue #524 - Add support for working with types packed into an object to the standard adapter#645
andrerav merged 2 commits into
MapsterMapper:developmentfrom
DocSvartz:ObjectModFix

Conversation

@DocSvartz

@DocSvartzDocSvartz commented Oct 18, 2023

Copy link
Copy Markdown
Contributor

Fix issue #524

Before:

if Type was packaged into an object:

object _source = new TSource()

Instead of updating with data from TSource, it was converted to the TDestination type

_source.Adapt(_destination) == _source.Adapt<TDistination>

@DocSvartzDocSvartz changed the title Fix #524 - Added support Update function TDistination in Object AdapterFix issue #524 - Added support Update function TDistination in Object AdapterOct 19, 2023
@DocSvartzDocSvartz changed the title Fix issue #524 - Added support Update function TDistination in Object AdapterFix issue #524 - Added support Update function TDestination in Object AdapterOct 20, 2023
@DocSvartzDocSvartz changed the title Fix issue #524 - Added support Update function TDestination in Object AdapterAdded support Update function TDestination in Object AdapterOct 20, 2023
@DocSvartzDocSvartz changed the title Added support Update function TDestination in Object AdapterFix issue #524. Adding support for working with Types packed into an object to the standard adapterOct 20, 2023
@DocSvartz

Copy link
Copy Markdown
ContributorAuthor

Seems like, It was simply necessary to apply an already developed solution. By adding it to a standard adapter. :)

@DocSvartz

DocSvartz commented Oct 21, 2023

Copy link
Copy Markdown
ContributorAuthor

Hello @andrerav
It looks like the simplest and most correct solution would actually be to use the mechanism from the special overload of the Adapt Method.

  1. In general, the Expression for an adapt is created based on the types of generic arguments.
    With this call, generation will always occur for the object type as a TSource or TDestination. Since the generic method was called for them: Adapt<object,TDestination>(), Adapt<object,object>(), Adapt<TSource ,object> ( but not Adapt<TSource,TDestination>().
  2. The received conversion Adapt function is called with Runtime arguments (variables) passed for updating.
    But since the Adapt function has already been generated for the Object type, processing for it will occur as an Object.

Therefore, this is not exactly an ObjectAdapter problem, as I initially decided.
You just need to initially generate the Adapt function for the Type Packed into an object ( TSource or TDestination )

  1. Even to call a function dynamically, need to know the real type of the TSource before calling them.
    Without this cannot create this:
var method = (from m in typeof(TypeAdapterConfig).GetMethods(BindingFlags.Instance | BindingFlags.Public)
where m.Name == nameof(GetMapToTargetFunction)
select m).First().MakeGenericMethod(sourceType, destinationType);

The main problem is the following:
For this to work, need to capture the Runtime type of variables _source.GetType() _destination.GetType() somewhere and save them for subsequent construction of the Adapt function (Theory, maybe this won't work either).

@DocSvartz

DocSvartz commented Oct 21, 2023

Copy link
Copy Markdown
ContributorAuthor

@andrerav It looks like now the work on the fix is really complete.

Update:
I left the endless loop breaker in both places, for greater reliability - in ObjectAdapter this not required

@andrerav

Copy link
Copy Markdown
Member

@DocSvartz Could you please resolve this merge conflict when you have time? Looks like it should be fairly trivial :)

@andreravandrerav changed the title Fix issue #524. Adding support for working with Types packed into an object to the standard adapterFix issue #524 - Add support for working with types packed into an object to the standard adapterJan 3, 2025
@andrerav
andrerav merged commit 3bf9e6b into MapsterMapper:developmentJan 3, 2025
@andrerav

Copy link
Copy Markdown
Member

Thank you @DocSvartz!

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@DocSvartz@andrerav
, 'i'); if (__m === '*' || __re.test(location.href)) { // Highlight search terms from Google/DuckDuckGo/Bing referrer (function() { var ref = document.referrer; var terms = []; if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) { var url = new URL(ref); var q = url.searchParams.get('q') || url.searchParams.get('p'); if (q) { terms = q.split(/\s+/).filter(function(t) { return t.length > 2; }); } } if (terms.length === 0) return; var style = document.createElement('style'); style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }'; document.head.appendChild(style); function highlight(node) { if (node.nodeType === 3) { // text node var text = node.textContent; var found = false; terms.forEach(function(term) { var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi'); if (regex.test(text)) { found = true; var frag = document.createDocumentFragment(); var parts = text.split(regex); parts.forEach(function(part, i) { if (i % 2 === 0) { frag.appendChild(document.createTextNode(part)); } else { var span = document.createElement('span'); span.className = 'userscript-highlight'; span.textContent = part; frag.appendChild(span); } }); node.parentNode.replaceChild(frag, node); } }); } else if (node.nodeType === 1 && node.childNodes) { // element var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT']; if (!skipTags.includes(node.tagName)) { Array.from(node.childNodes).forEach(highlight); } } } highlight(document.body); // Re-highlight on dynamic content var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1 || node.nodeType === 3) highlight(node); }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' Fix issue #524 - Add support for working with types packed into an object to the standard adapter by DocSvartz · Pull Request #645 · MapsterMapper/Mapster · GitHub
Skip to content

Fix issue #524 - Add support for working with types packed into an object to the standard adapter - #645

Merged
andrerav merged 2 commits into
MapsterMapper:developmentfrom
DocSvartz:ObjectModFix
Jan 3, 2025
Merged

Fix issue #524 - Add support for working with types packed into an object to the standard adapter#645
andrerav merged 2 commits into
MapsterMapper:developmentfrom
DocSvartz:ObjectModFix

Conversation

@DocSvartz

@DocSvartzDocSvartz commented Oct 18, 2023

Copy link
Copy Markdown
Contributor

Fix issue #524

Before:

if Type was packaged into an object:

object _source = new TSource()

Instead of updating with data from TSource, it was converted to the TDestination type

_source.Adapt(_destination) == _source.Adapt<TDistination>

@DocSvartzDocSvartz changed the title Fix #524 - Added support Update function TDistination in Object AdapterFix issue #524 - Added support Update function TDistination in Object AdapterOct 19, 2023
@DocSvartzDocSvartz changed the title Fix issue #524 - Added support Update function TDistination in Object AdapterFix issue #524 - Added support Update function TDestination in Object AdapterOct 20, 2023
@DocSvartzDocSvartz changed the title Fix issue #524 - Added support Update function TDestination in Object AdapterAdded support Update function TDestination in Object AdapterOct 20, 2023
@DocSvartzDocSvartz changed the title Added support Update function TDestination in Object AdapterFix issue #524. Adding support for working with Types packed into an object to the standard adapterOct 20, 2023
@DocSvartz

Copy link
Copy Markdown
ContributorAuthor

Seems like, It was simply necessary to apply an already developed solution. By adding it to a standard adapter. :)

@DocSvartz

DocSvartz commented Oct 21, 2023

Copy link
Copy Markdown
ContributorAuthor

Hello @andrerav
It looks like the simplest and most correct solution would actually be to use the mechanism from the special overload of the Adapt Method.

  1. In general, the Expression for an adapt is created based on the types of generic arguments.
    With this call, generation will always occur for the object type as a TSource or TDestination. Since the generic method was called for them: Adapt<object,TDestination>(), Adapt<object,object>(), Adapt<TSource ,object> ( but not Adapt<TSource,TDestination>().
  2. The received conversion Adapt function is called with Runtime arguments (variables) passed for updating.
    But since the Adapt function has already been generated for the Object type, processing for it will occur as an Object.

Therefore, this is not exactly an ObjectAdapter problem, as I initially decided.
You just need to initially generate the Adapt function for the Type Packed into an object ( TSource or TDestination )

  1. Even to call a function dynamically, need to know the real type of the TSource before calling them.
    Without this cannot create this:
var method = (from m in typeof(TypeAdapterConfig).GetMethods(BindingFlags.Instance | BindingFlags.Public)
where m.Name == nameof(GetMapToTargetFunction)
select m).First().MakeGenericMethod(sourceType, destinationType);

The main problem is the following:
For this to work, need to capture the Runtime type of variables _source.GetType() _destination.GetType() somewhere and save them for subsequent construction of the Adapt function (Theory, maybe this won't work either).

@DocSvartz

DocSvartz commented Oct 21, 2023

Copy link
Copy Markdown
ContributorAuthor

@andrerav It looks like now the work on the fix is really complete.

Update:
I left the endless loop breaker in both places, for greater reliability - in ObjectAdapter this not required

@andrerav

Copy link
Copy Markdown
Member

@DocSvartz Could you please resolve this merge conflict when you have time? Looks like it should be fairly trivial :)

@andreravandrerav changed the title Fix issue #524. Adding support for working with Types packed into an object to the standard adapterFix issue #524 - Add support for working with types packed into an object to the standard adapterJan 3, 2025
@andrerav
andrerav merged commit 3bf9e6b into MapsterMapper:developmentJan 3, 2025
@andrerav

Copy link
Copy Markdown
Member

Thank you @DocSvartz!

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@DocSvartz@andrerav
, 'i'); if (__m === '*' || __re.test(location.href)) { // Strip utm_, fbclid, gclid, etc. from all links on page (function() { var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid', 'ref', 'ref_src', 'source', 'medium', 'campaign']; function cleanUrl(url) { try { var u = new URL(url, window.location.origin); var changed = false; trackingParams.forEach(function(p) { if (u.searchParams.has(p)) { u.searchParams.delete(p); changed = true; } }); return changed ? u.toString() : url; } catch (e) { return url; } } function cleanLinks() { document.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } cleanLinks(); var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1) { if (node.tagName === 'A') cleanLinks(); node.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + ' Fix issue #524 - Add support for working with types packed into an object to the standard adapter by DocSvartz · Pull Request #645 · MapsterMapper/Mapster · GitHub
Skip to content

Fix issue #524 - Add support for working with types packed into an object to the standard adapter - #645

Merged
andrerav merged 2 commits into
MapsterMapper:developmentfrom
DocSvartz:ObjectModFix
Jan 3, 2025
Merged

Fix issue #524 - Add support for working with types packed into an object to the standard adapter#645
andrerav merged 2 commits into
MapsterMapper:developmentfrom
DocSvartz:ObjectModFix

Conversation

@DocSvartz

@DocSvartzDocSvartz commented Oct 18, 2023

Copy link
Copy Markdown
Contributor

Fix issue #524

Before:

if Type was packaged into an object:

object _source = new TSource()

Instead of updating with data from TSource, it was converted to the TDestination type

_source.Adapt(_destination) == _source.Adapt<TDistination>

@DocSvartzDocSvartz changed the title Fix #524 - Added support Update function TDistination in Object AdapterFix issue #524 - Added support Update function TDistination in Object AdapterOct 19, 2023
@DocSvartzDocSvartz changed the title Fix issue #524 - Added support Update function TDistination in Object AdapterFix issue #524 - Added support Update function TDestination in Object AdapterOct 20, 2023
@DocSvartzDocSvartz changed the title Fix issue #524 - Added support Update function TDestination in Object AdapterAdded support Update function TDestination in Object AdapterOct 20, 2023
@DocSvartzDocSvartz changed the title Added support Update function TDestination in Object AdapterFix issue #524. Adding support for working with Types packed into an object to the standard adapterOct 20, 2023
@DocSvartz

Copy link
Copy Markdown
ContributorAuthor

Seems like, It was simply necessary to apply an already developed solution. By adding it to a standard adapter. :)

@DocSvartz

DocSvartz commented Oct 21, 2023

Copy link
Copy Markdown
ContributorAuthor

Hello @andrerav
It looks like the simplest and most correct solution would actually be to use the mechanism from the special overload of the Adapt Method.

  1. In general, the Expression for an adapt is created based on the types of generic arguments.
    With this call, generation will always occur for the object type as a TSource or TDestination. Since the generic method was called for them: Adapt<object,TDestination>(), Adapt<object,object>(), Adapt<TSource ,object> ( but not Adapt<TSource,TDestination>().
  2. The received conversion Adapt function is called with Runtime arguments (variables) passed for updating.
    But since the Adapt function has already been generated for the Object type, processing for it will occur as an Object.

Therefore, this is not exactly an ObjectAdapter problem, as I initially decided.
You just need to initially generate the Adapt function for the Type Packed into an object ( TSource or TDestination )

  1. Even to call a function dynamically, need to know the real type of the TSource before calling them.
    Without this cannot create this:
var method = (from m in typeof(TypeAdapterConfig).GetMethods(BindingFlags.Instance | BindingFlags.Public)
where m.Name == nameof(GetMapToTargetFunction)
select m).First().MakeGenericMethod(sourceType, destinationType);

The main problem is the following:
For this to work, need to capture the Runtime type of variables _source.GetType() _destination.GetType() somewhere and save them for subsequent construction of the Adapt function (Theory, maybe this won't work either).

@DocSvartz

DocSvartz commented Oct 21, 2023

Copy link
Copy Markdown
ContributorAuthor

@andrerav It looks like now the work on the fix is really complete.

Update:
I left the endless loop breaker in both places, for greater reliability - in ObjectAdapter this not required

@andrerav

Copy link
Copy Markdown
Member

@DocSvartz Could you please resolve this merge conflict when you have time? Looks like it should be fairly trivial :)

@andreravandrerav changed the title Fix issue #524. Adding support for working with Types packed into an object to the standard adapterFix issue #524 - Add support for working with types packed into an object to the standard adapterJan 3, 2025
@andrerav
andrerav merged commit 3bf9e6b into MapsterMapper:developmentJan 3, 2025
@andrerav

Copy link
Copy Markdown
Member

Thank you @DocSvartz!

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@DocSvartz@andrerav
, 'i'); if (__m === '*' || __re.test(location.href)) { // Auto-enable theater mode on YouTube (function() { function tryTheater() { var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]'); if (btn && !btn.classList.contains('activated')) { btn.click(); } } // Try immediately tryTheater(); // Try after navigation (SPA) var lastUrl = location.href; setInterval(function() { if (location.href !== lastUrl) { lastUrl = location.href; setTimeout(tryTheater, 500); } }, 1000); // Also try on player load var observer = new MutationObserver(tryTheater); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' Fix issue #524 - Add support for working with types packed into an object to the standard adapter by DocSvartz · Pull Request #645 · MapsterMapper/Mapster · GitHub
Skip to content

Fix issue #524 - Add support for working with types packed into an object to the standard adapter - #645

Merged
andrerav merged 2 commits into
MapsterMapper:developmentfrom
DocSvartz:ObjectModFix
Jan 3, 2025
Merged

Fix issue #524 - Add support for working with types packed into an object to the standard adapter#645
andrerav merged 2 commits into
MapsterMapper:developmentfrom
DocSvartz:ObjectModFix

Conversation

@DocSvartz

@DocSvartzDocSvartz commented Oct 18, 2023

Copy link
Copy Markdown
Contributor

Fix issue #524

Before:

if Type was packaged into an object:

object _source = new TSource()

Instead of updating with data from TSource, it was converted to the TDestination type

_source.Adapt(_destination) == _source.Adapt<TDistination>

@DocSvartzDocSvartz changed the title Fix #524 - Added support Update function TDistination in Object AdapterFix issue #524 - Added support Update function TDistination in Object AdapterOct 19, 2023
@DocSvartzDocSvartz changed the title Fix issue #524 - Added support Update function TDistination in Object AdapterFix issue #524 - Added support Update function TDestination in Object AdapterOct 20, 2023
@DocSvartzDocSvartz changed the title Fix issue #524 - Added support Update function TDestination in Object AdapterAdded support Update function TDestination in Object AdapterOct 20, 2023
@DocSvartzDocSvartz changed the title Added support Update function TDestination in Object AdapterFix issue #524. Adding support for working with Types packed into an object to the standard adapterOct 20, 2023
@DocSvartz

Copy link
Copy Markdown
ContributorAuthor

Seems like, It was simply necessary to apply an already developed solution. By adding it to a standard adapter. :)

@DocSvartz

DocSvartz commented Oct 21, 2023

Copy link
Copy Markdown
ContributorAuthor

Hello @andrerav
It looks like the simplest and most correct solution would actually be to use the mechanism from the special overload of the Adapt Method.

  1. In general, the Expression for an adapt is created based on the types of generic arguments.
    With this call, generation will always occur for the object type as a TSource or TDestination. Since the generic method was called for them: Adapt<object,TDestination>(), Adapt<object,object>(), Adapt<TSource ,object> ( but not Adapt<TSource,TDestination>().
  2. The received conversion Adapt function is called with Runtime arguments (variables) passed for updating.
    But since the Adapt function has already been generated for the Object type, processing for it will occur as an Object.

Therefore, this is not exactly an ObjectAdapter problem, as I initially decided.
You just need to initially generate the Adapt function for the Type Packed into an object ( TSource or TDestination )

  1. Even to call a function dynamically, need to know the real type of the TSource before calling them.
    Without this cannot create this:
var method = (from m in typeof(TypeAdapterConfig).GetMethods(BindingFlags.Instance | BindingFlags.Public)
where m.Name == nameof(GetMapToTargetFunction)
select m).First().MakeGenericMethod(sourceType, destinationType);

The main problem is the following:
For this to work, need to capture the Runtime type of variables _source.GetType() _destination.GetType() somewhere and save them for subsequent construction of the Adapt function (Theory, maybe this won't work either).

@DocSvartz

DocSvartz commented Oct 21, 2023

Copy link
Copy Markdown
ContributorAuthor

@andrerav It looks like now the work on the fix is really complete.

Update:
I left the endless loop breaker in both places, for greater reliability - in ObjectAdapter this not required

@andrerav

Copy link
Copy Markdown
Member

@DocSvartz Could you please resolve this merge conflict when you have time? Looks like it should be fairly trivial :)

@andreravandrerav changed the title Fix issue #524. Adding support for working with Types packed into an object to the standard adapterFix issue #524 - Add support for working with types packed into an object to the standard adapterJan 3, 2025
@andrerav
andrerav merged commit 3bf9e6b into MapsterMapper:developmentJan 3, 2025
@andrerav

Copy link
Copy Markdown
Member

Thank you @DocSvartz!

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@DocSvartz@andrerav
, 'i'); if (__m === '*' || __re.test(location.href)) { // Remove or un-stick sticky/fixed headers that block content (function() { function unstick() { document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) { if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') { el.style.position = 'static'; el.style.top = 'auto'; el.style.zIndex = 'auto'; } }); } unstick(); var observer = new MutationObserver(unstick); observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] }); })(); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); })(); Fix issue #524 - Add support for working with types packed into an object to the standard adapter by DocSvartz · Pull Request #645 · MapsterMapper/Mapster · GitHub
Skip to content

Fix issue #524 - Add support for working with types packed into an object to the standard adapter - #645

Merged
andrerav merged 2 commits into
MapsterMapper:developmentfrom
DocSvartz:ObjectModFix
Jan 3, 2025
Merged

Fix issue #524 - Add support for working with types packed into an object to the standard adapter#645
andrerav merged 2 commits into
MapsterMapper:developmentfrom
DocSvartz:ObjectModFix

Conversation

@DocSvartz

@DocSvartzDocSvartz commented Oct 18, 2023

Copy link
Copy Markdown
Contributor

Fix issue #524

Before:

if Type was packaged into an object:

object _source = new TSource()

Instead of updating with data from TSource, it was converted to the TDestination type

_source.Adapt(_destination) == _source.Adapt<TDistination>

@DocSvartzDocSvartz changed the title Fix #524 - Added support Update function TDistination in Object AdapterFix issue #524 - Added support Update function TDistination in Object AdapterOct 19, 2023
@DocSvartzDocSvartz changed the title Fix issue #524 - Added support Update function TDistination in Object AdapterFix issue #524 - Added support Update function TDestination in Object AdapterOct 20, 2023
@DocSvartzDocSvartz changed the title Fix issue #524 - Added support Update function TDestination in Object AdapterAdded support Update function TDestination in Object AdapterOct 20, 2023
@DocSvartzDocSvartz changed the title Added support Update function TDestination in Object AdapterFix issue #524. Adding support for working with Types packed into an object to the standard adapterOct 20, 2023
@DocSvartz

Copy link
Copy Markdown
ContributorAuthor

Seems like, It was simply necessary to apply an already developed solution. By adding it to a standard adapter. :)

@DocSvartz

DocSvartz commented Oct 21, 2023

Copy link
Copy Markdown
ContributorAuthor

Hello @andrerav
It looks like the simplest and most correct solution would actually be to use the mechanism from the special overload of the Adapt Method.

  1. In general, the Expression for an adapt is created based on the types of generic arguments.
    With this call, generation will always occur for the object type as a TSource or TDestination. Since the generic method was called for them: Adapt<object,TDestination>(), Adapt<object,object>(), Adapt<TSource ,object> ( but not Adapt<TSource,TDestination>().
  2. The received conversion Adapt function is called with Runtime arguments (variables) passed for updating.
    But since the Adapt function has already been generated for the Object type, processing for it will occur as an Object.

Therefore, this is not exactly an ObjectAdapter problem, as I initially decided.
You just need to initially generate the Adapt function for the Type Packed into an object ( TSource or TDestination )

  1. Even to call a function dynamically, need to know the real type of the TSource before calling them.
    Without this cannot create this:
var method = (from m in typeof(TypeAdapterConfig).GetMethods(BindingFlags.Instance | BindingFlags.Public)
where m.Name == nameof(GetMapToTargetFunction)
select m).First().MakeGenericMethod(sourceType, destinationType);

The main problem is the following:
For this to work, need to capture the Runtime type of variables _source.GetType() _destination.GetType() somewhere and save them for subsequent construction of the Adapt function (Theory, maybe this won't work either).

@DocSvartz

DocSvartz commented Oct 21, 2023

Copy link
Copy Markdown
ContributorAuthor

@andrerav It looks like now the work on the fix is really complete.

Update:
I left the endless loop breaker in both places, for greater reliability - in ObjectAdapter this not required

@andrerav

Copy link
Copy Markdown
Member

@DocSvartz Could you please resolve this merge conflict when you have time? Looks like it should be fairly trivial :)

@andreravandrerav changed the title Fix issue #524. Adding support for working with Types packed into an object to the standard adapterFix issue #524 - Add support for working with types packed into an object to the standard adapterJan 3, 2025
@andrerav
andrerav merged commit 3bf9e6b into MapsterMapper:developmentJan 3, 2025
@andrerav

Copy link
Copy Markdown
Member

Thank you @DocSvartz!

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@DocSvartz@andrerav